That is how we do business now, over TCP. By the way, I downloaded a new derivative of Mysql, http://paralleluniverse-inc.com/, and it seems, in my tests, several times faster than any other version, at least for this query select count(*) from table; where table has 550 million records. I have the exact same table on Mariadb and regular mysql, and it takes around 10 times longer to get the result, on the same vmware datastore. Do I have to think that this results are not real and I am perhaps doing something wrong? If anybody can test this free technology, I would be grateful. They claim to work in parallel.
On Tue, Nov 11, 2014 at 3:33 PM, Michael H. Warfield <m...@wittsend.com> wrote: > On Tue, 2014-11-11 at 15:03 -0500, CDR wrote: > > This is fascinating. I will try and report if it does work. > > > Now, suppose the container is a mount that at the same time it is > > exported an NFS share. Will the computers that are remotely mounting > > that share, be able to use the socket for querying mysql? That opens a > > realm of possibilities for my current business. Believe or not my > > client sells access to mysql databases, in real time. > > Not going to work. Think about it. You're exporting an AF_UNIX (local > pipe) socket defined in a directory over a UDP RPC interface. The other > side will (if it understands it) see an AF_UNIX socket local to them. > They won't be connected. That will be true of just about any remote > file system. > > You also said in your OP... > > > It is much faster and uses far less resources than tcp. Does this make > > any sense? > > So, you'd be replacing TCP with a UNIX socket over RPC over UDP and > expect that to be more efficient? You've got a higher respect for NFS > than most of us. Over NFS, that scheme would consume more resources, > even if it could work. > > It won't work and, even if it could work, it would be dog slow and > probably insecure. > > Use TCP for your remote connections and a locally bound UNIX socket for > your host local connections. If you have to have the connections be > homogeneous, then go with TCP. From your description of that business > model, unless you are transferring truly massive amounts of data per SQL > query, the performance of the TCP connection for your local > container-to-container connections is not going to be your bottleneck > and NFS would only make things worse. > > > On Tue, Nov 11, 2014 at 2:52 PM, Serge Hallyn > > <serge.hal...@ubuntu.com> wrote: > > Quoting Michael H. Warfield (m...@wittsend.com): > > > On Tue, 2014-11-11 at 20:20 +0100, Hans Feldt wrote: > > > > With a dir potentially you get a bunch of other sockets > > available in the container, how can such > > > > security issue be handled? > > > > > > Use tailored application specific directories for the > > sockets? That's > > > no different than using application specific subdirectories > > for temp > > > files. Even if it's just one socket in one directory, > > creating that > > > additional directory provides the isolation from other > > sockets you > > > desire while supporting socket recreation as Serge points > > out. > > > > Right, I was thinking like how cgmanager does it. > > > > -serge > > _______________________________________________ > > lxc-users mailing list > > lxc-users@lists.linuxcontainers.org > > http://lists.linuxcontainers.org/listinfo/lxc-users > > > > > > _______________________________________________ > > lxc-users mailing list > > lxc-users@lists.linuxcontainers.org > > http://lists.linuxcontainers.org/listinfo/lxc-users > > -- > Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com > /\/\|=mhw=|\/\/ | (678) 463-0932 | > http://www.wittsend.com/mhw/ > NIC whois: MHW9 | An optimist believes we live in the best of > all > PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! > > > _______________________________________________ > lxc-users mailing list > lxc-users@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-users >
_______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users