[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