Date: Fri, 16 Jun 2000 02:57:23 -0700 From: Peter Wemm <peter@netplex.com.au> To: Marc Slemko <marcs@znep.com> Cc: "Daniel O'Connor" <doconnor@gsoft.com.au>, "Daniel C. Sobral" <dcs@newsguy.com>, Alfred Perlstein <alfred@FreeBSD.org>, Nate Williams <nate@yogotech.com>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_socket.c uipc_socket2.c src/sy Message-ID: <20000616095723.6C4771CD7@overcee.netplex.com.au> In-Reply-To: Message from Marc Slemko <marcs@znep.com> of "Thu, 15 Jun 2000 22:10:24 PDT." <Pine.GSO.4.21.0006152204370.14352-100000@redfish>
next in thread | previous in thread | raw e-mail | index | archive | help
Marc Slemko wrote:
> On Fri, 16 Jun 2000, Daniel O'Connor wrote:
>
> > > The correct here is find _why_ there is a performance impact if this
> > > delay accept feature is not used, and fix _that_ instead.
> >
> > Well, my naivity abounds, but I would have thought it was because you do an
> > accept() which returns and then immediatly you go back to waiting on select
().
>
> Why should that be expensive?
Context switches are *extremely* expensive, relative to doing useful work.
> If thundering herd on accept() is a problem, add a wake_one. Which
> was done.
The problem is this:
1: Connection arrives
2: accept() completes
3: context switch to run process to accept it.
4: process runs and immediately calls read()
5: in many cases we did not get a complete header. If not, context switch
and goto step 4. ie: several context switches to get the header.
6: process request
7: write data
8: close
9: idle, or context switch to something else
The problem is the 4/5 loop. If the browser writes the request piecemeal
(too many do), you are going to have 5 or 10 or more context switches until
you get the header. Even if the browser sends the data in one packet and
one push, you still have a context switch after accept returns and before
read() can get it.
With setsockopt(s, ... HTTPACCEPT ..., this happens:
1: connection arrives
2: data is gathered in kernel context
3: when a full GET request is complete, accept() completes
4: context switch to run process ot accept it (same as 3 above)
5: read() gets the full request in one gulp
6: process request (same as 6 above)
7: write data
8: close
9: idle, or context switch to something else
Note all the context switches in step 4 and 5 are gone. 99.9% of the time
you can do everything on the single context if you hold off until either
you have a complete GET request or have something that you cannot safely
handle (in that case you punt to the process and let it deal with it).
> If there is some similar problem elsewhere, fix it.
The problem is not the implemetation, the problem is the HTTP protocol.
We cannot "fix" all the Win9x and netscape/IE browsers to use some HTTP
replacement or enhancement.
This is a cheap tweak that has a *MASSIVE* performance win in the most
performance critical of all the internet protocols. To the bulk of the
population that is internet aware, the internet == HTTP/HTML. If there is
anywhere that we can get a cheap, easy win that has very large payback,
this is it. As I understand it, on the yahoo.com servers we can get an
order of magnitude or so extra performance out of a box as a result of
this. It most certainly has real-world applications.
(FYI, we have FTP and real-audio support code in the netinet stack)
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000616095723.6C4771CD7>