From: Willy Tarreau <w@1wt.eu>
To: Olaf van der Spek <olafvdspek@gmail.com>
Cc: David Miller <davem@davemloft.net>,
jrm8005@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: Unix sockets via TCP on localhost: is TCP slower?
Date: Fri, 14 Nov 2008 22:07:59 +0100 [thread overview]
Message-ID: <20081114210759.GX24654@1wt.eu> (raw)
In-Reply-To: <b2cc26e40811140109jfc6b0f3tf33a92afbff33e46@mail.gmail.com>
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@davemloft.net> 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
next prev parent reply other threads:[~2008-11-14 21:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-12 23:20 Unix sockets via TCP on localhost: is TCP slower? Olaf van der Spek
2008-11-13 11:24 ` Arnaldo Carvalho de Melo
2008-11-13 19:06 ` Olaf van der Spek
2008-11-13 23:04 ` Chris Friesen
2008-11-14 0:19 ` J.R. Mauro
2008-11-14 0:22 ` David Miller
2008-11-14 0:27 ` J.R. Mauro
2008-11-14 8:51 ` Olaf van der Spek
2008-11-14 8:54 ` Eric Dumazet
2008-11-14 9:06 ` Olaf van der Spek
2008-11-14 13:14 ` J.R. Mauro
2008-11-14 8:56 ` David Miller
2008-11-14 9:09 ` Olaf van der Spek
2008-11-14 10:37 ` Bernd Petrovitsch
2008-11-14 13:17 ` J.R. Mauro
2008-11-14 21:07 ` Willy Tarreau [this message]
2008-11-14 22:40 ` Olaf van der Spek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081114210759.GX24654@1wt.eu \
--to=w@1wt.eu \
--cc=davem@davemloft.net \
--cc=jrm8005@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=olafvdspek@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox