[lxc-users] Unix Sockets communications between containers

CDR venefax at gmail.com
Wed Nov 12 02:27:38 UTC 2014


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 <mhw at 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.hallyn at ubuntu.com> wrote:
> >         Quoting Michael H. Warfield (mhw at 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 at lists.linuxcontainers.org
> >         http://lists.linuxcontainers.org/listinfo/lxc-users
> >
> >
> > _______________________________________________
> > lxc-users mailing list
> > lxc-users at lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
>
> --
> Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at 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 at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20141111/4df4d328/attachment.html>


More information about the lxc-users mailing list