<div dir="ltr"><div class="gmail_default" style="font-size:large">That is how we do business now, over TCP. By the way, I downloaded a new derivative of Mysql, <a href="http://paralleluniverse-inc.com/">http://paralleluniverse-inc.com/</a>, and it seems, in my tests, several times faster than any other version, at least for this query<br></div><div class="gmail_default" style="font-size:large">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.<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 11, 2014 at 3:33 PM, Michael H. Warfield <span dir="ltr"><<a href="mailto:mhw@wittsend.com" target="_blank">mhw@wittsend.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, 2014-11-11 at 15:03 -0500, CDR wrote:<br>
> This is fascinating. I will try and report if it does work.<br>
<br>
> Now, suppose the container is a mount that at the same time it is<br>
> exported an NFS share. Will the computers that are remotely mounting<br>
> that share, be able to use the socket for querying mysql? That opens a<br>
> realm of possibilities for my current business. Believe or not my<br>
> client sells access to mysql databases, in real time.<br>
<br>
</span>Not going to work. Think about it. You're exporting an AF_UNIX (local<br>
pipe) socket defined in a directory over a UDP RPC interface. The other<br>
side will (if it understands it) see an AF_UNIX socket local to them.<br>
They won't be connected. That will be true of just about any remote<br>
file system.<br>
<br>
You also said in your OP...<br>
<span class=""><br>
> It is much faster and uses far less resources than tcp. Does this make<br>
> any sense?<br>
<br>
</span>So, you'd be replacing TCP with a UNIX socket over RPC over UDP and<br>
expect that to be more efficient? You've got a higher respect for NFS<br>
than most of us. Over NFS, that scheme would consume more resources,<br>
even if it could work.<br>
<br>
It won't work and, even if it could work, it would be dog slow and<br>
probably insecure.<br>
<br>
Use TCP for your remote connections and a locally bound UNIX socket for<br>
your host local connections. If you have to have the connections be<br>
homogeneous, then go with TCP. From your description of that business<br>
model, unless you are transferring truly massive amounts of data per SQL<br>
query, the performance of the TCP connection for your local<br>
container-to-container connections is not going to be your bottleneck<br>
and NFS would only make things worse.<br>
<div class="HOEnZb"><div class="h5"><br>
> On Tue, Nov 11, 2014 at 2:52 PM, Serge Hallyn<br>
> <<a href="mailto:serge.hallyn@ubuntu.com">serge.hallyn@ubuntu.com</a>> wrote:<br>
> Quoting Michael H. Warfield (mhw@WittsEnd.com):<br>
> > On Tue, 2014-11-11 at 20:20 +0100, Hans Feldt wrote:<br>
> > > With a dir potentially you get a bunch of other sockets<br>
> available in the container, how can such<br>
> > > security issue be handled?<br>
> ><br>
> > Use tailored application specific directories for the<br>
> sockets? That's<br>
> > no different than using application specific subdirectories<br>
> for temp<br>
> > files. Even if it's just one socket in one directory,<br>
> creating that<br>
> > additional directory provides the isolation from other<br>
> sockets you<br>
> > desire while supporting socket recreation as Serge points<br>
> out.<br>
><br>
> Right, I was thinking like how cgmanager does it.<br>
><br>
> -serge<br>
> _______________________________________________<br>
> lxc-users mailing list<br>
> <a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.linuxcontainers.org</a><br>
> <a href="http://lists.linuxcontainers.org/listinfo/lxc-users" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a><br>
><br>
><br>
> _______________________________________________<br>
> lxc-users mailing list<br>
> <a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.linuxcontainers.org</a><br>
> <a href="http://lists.linuxcontainers.org/listinfo/lxc-users" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a><br>
<br>
</div></div><div class="HOEnZb"><div class="h5">--<br>
Michael H. Warfield (AI4NB) | <a href="tel:%28770%29%20978-7061" value="+17709787061">(770) 978-7061</a> | mhw@WittsEnd.com<br>
/\/\|=mhw=|\/\/ | <a href="tel:%28678%29%20463-0932" value="+16784630932">(678) 463-0932</a> | <a href="http://www.wittsend.com/mhw/" target="_blank">http://www.wittsend.com/mhw/</a><br>
NIC whois: MHW9 | An optimist believes we live in the best of all<br>
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!<br>
<br>
</div></div><br>_______________________________________________<br>
lxc-users mailing list<br>
<a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.linuxcontainers.org</a><br>
<a href="http://lists.linuxcontainers.org/listinfo/lxc-users" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a><br></blockquote></div><br></div>