Re: Unix sockets via TCP on localhost: is TCP slower?

From: Willy Tarreau
Date: Fri Nov 14 2008 - 16:08:19 EST


On Fri, Nov 14, 2008 at 10:09:25AM +0100, Olaf van der Spek wrote:
> On Fri, Nov 14, 2008 at 9:56 AM, David Miller <davem@xxxxxxxxxxxxx> wrote:
> >> Why would you use windowing, ACKs, flow control and encapsulation on localhost?
> >
> > So that you could firewall, shape, redirect, and make other
> > modifications to the traffic, as well as see it in tcpdumps. That's
> > the power of Linux, and yes people do this stuff and yes people do
> > want these features to work over loopback.
> >
> >> I expected the kernel to copy data directly from user-space of the
> >> sending process to a kernel buffer of the receiving process, much like
> >> UNIX sockets.
> >
> > Then all of the above features and debugging facilities go away.
>
> So instead the recommendation is for all apps to support both TCP and
> Unix sockets?
> If you then use Unix sockets, you still lose all of those facilities
> and as a bonus, your apps are more complex.
>
> I'd prefer a switch that could be enabled to use such a shortcut for TCP.
> Firewalls should still work mostly (on connect), redirect would still work.

I'm already wondering what problems you encounter with TCP performance
on the loopback. I'm used to stress-test network proxies on the loopback
for quick tests when I don't want to boot 3 machines, and seeing that it's
easy to connect/accept 100k sessions/s and forward about 20-30 Gbps between
two processes on consumer-grade machines, I'm really doubting that your
applications needs that much out of your database.

If you're really so sensible to local traffic tunning, you can already
set a very large MTU on your loopback, you can have very large windows
between your applications so that very few ACKs are sent, etc... And
BTW checksums are already not even computed. Loopback *is* fast, there's
no need to crapify the whole stack with your "switch" to gain 5% more out
of it.

Anyway, if you can come up with patches which proves all of us wrong
without weakening the code, I'm sure they could be accepted.

Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/