public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dan Kegel <dank@kegel.com>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	x@xman.org
Subject: Re: Improving (network) IO performance ...
Date: Thu, 12 Jul 2001 08:18:52 -0700	[thread overview]
Message-ID: <3B4DBFDC.91C27FFB@kegel.com> (raw)
In-Reply-To: <XFMail.20010711220804.davidel@xmailserver.org>

Davide Libenzi wrote:
> 
> On 12-Jul-2001 Dan Kegel wrote:
> > Very cool.  Thanks for doing a no-scan implementation of /dev/poll!
> > Two questions:
> >
> > 1) have you compared its performance against Vitaly Luban's
> > signal-per-fd patch?  Even though it's realtime-signal based,
> > there's some hope for it being quite efficient.  See
> > http://www.luban.org/GPL/gpl.html and
> > http://boudicca.tux.org/hypermail/linux-kernel/2001week20/1353.html
> 
> There's more than the event collapsing inside the patch.
> I saw the Luban's work but I decided to use the Lever-Provos /dev/poll as a
> performance meter ( and the old poll() obviously ).
> This coz I read papers where RT signals implementations resulted to have less
> performance when compared to /dev/poll.

It was absolutely great that you benchmarked it relative to the Lever-Provos
/dev/poll, since that made it quite clear yours scaled much better than theirs
to large numbers of idle sockets.  

Perhaps somebody who uses the realtime signal - based readiness notifications
can enhance Davide's benchmark to also cover them (with and without Luban's patch)?
That would help those of us who are trying to decide whether to go with
/dev/poll or realtime signals.

> > 2) A little birdie told me that someone had gotten a freebsd
> > box to handle something like half a million connections.
> > I would like to see you extend the horizontal axis of your graph
> > by a couple orders of magnitude :-)
> 
> Here You can find the new statistics with 16000 connections :
> 
> http://www.xmailserver.org/linux-patches/nio-improve.html
> 
> I cannot reach that number of connections of the test machine coz the socket
> buffer space will eat all my memory ( 128 Mb ).
> Anyway the graph speaks quite clear about the tendency to greater numbers of
> connections.

Yes, in fact, it shows that adding more dead connections actually
improves performance using your patch :-)

Here's what the little birdie told me exactly:
> You'll be happy to know I've achieved over 500,000 connections
> on Pentium hardware with 4G of RAM and 2 1Gbit cards on FreeBSD 4.3.

I think the application was similar to your benchmark configuration;
no idea what the ratio of live to dead connections was.
Let's see: if you have 1/32nd as much RAM as she had, you ought to 
be able to handle 1/32nd as many connections, right?  Since you
hit 16000 connections, I guess you just about did.
- Dan

  reply	other threads:[~2001-07-12 15:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-12  0:39 Improving (network) IO performance Dan Kegel
2001-07-12  5:08 ` Davide Libenzi
2001-07-12 15:18   ` Dan Kegel [this message]
2001-07-12 15:34     ` Davide Libenzi
  -- strict thread matches above, loose matches on Subject: below --
2001-07-11 21:59 Davide Libenzi

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=3B4DBFDC.91C27FFB@kegel.com \
    --to=dank@kegel.com \
    --cc=davidel@xmailserver.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x@xman.org \
    /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