Date: Fri, 16 Jun 2000 19:02:37 -0700 From: Peter Wemm <peter@netplex.com.au> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: Marc Slemko <marcs@znep.com>, Alfred Perlstein <alfred@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_socket.c uipc_socket2.c src/sys/sys socket.h Message-ID: <20000617020237.0CF2A1CDF@overcee.netplex.com.au> In-Reply-To: Message from John-Mark Gurney <gurney_j@efn.org> of "Fri, 16 Jun 2000 11:25:31 PDT." <20000616112531.12083@hydrogen.funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney wrote:
> Marc Slemko scribbled this message on Jun 15:
> > On Thu, 15 Jun 2000, John-Mark Gurney wrote:
> >
> > > Alfred Perlstein scribbled this message on Jun 15:
> > > > until the incoming connection has either data waiting or what looks l
ike a
> > > > HTTP request header already in the socketbuffer. This ought to reduc
e
> > > > the context switch time and overhead for processing requests.
> > >
> > > if this code stays (which I hope it either gets removed, or made into
> > > a kld module), it should be updated to check for ALL the various
> > > possible http requests... (such as HEAD, etc.)
> >
> > Actually, no, it should not be a generalized to be fully able to grok
> > all possible requests. While I agree that this sort of hardcoded gunk
> > isn't necessarily appropriate where it is (or even useful for
> > performance, outside of very constrained benchmark situations), if you
> > are going to add special code to the kernel, then you want to keep a
> > small fast path in the kernel that covers the common case. You can
>
> and you want to make it loadable so that it doesn't bloat the kernel...
> tight performance optimizations that effect only a small subset of
> people are bad.. we have kld's make use of them...
Adding hooks generic enough to deal with this cost as much or more than
the original. If you think this is better, then how about lets see actual
real *CODE* and not just hot air.
> > cover 90% of the cases with 10% of the code, then everything else just
> > punts down the way things normally work. More speed for the common case,
> > less complexity, and a lot less chance of bugs.
>
> have you done a performance difference between the delayed accept version
> and the http version of the socket?? I REALLY doubt that many clients
> split the url into multiple packets, and if they do, they are in the
> minority which means we can take the hit for those...
When the requests are larger than the ethernet MTU, you can't help it.
Individual cookies can be up to (if I recall correctly) 1K-1 bytes long.
You can (and do) have many cookies, some persistant but mostly temporary.
The largest of these cookies are those that encode quite a bit of state for
dynamic HTML renderers.
> why doesn't the simple delay work? have you even tested the performance
> difference between the two for http?? I bet you will find that there
> is only a slight performance (like 1%) difference if that much as you
> don't have to pass it through two compare routines, and you just have
> to compare if there is data there...
I have just spoken with David Filo at length about this. It happens
a *lot*. Windows and older IE in particular are the worst offenders,
and then there are lots of wierd browsers that do really wierd stuff.
There are some browsers that send each *character* in a seperate TCP
packet. There are a significant number that send the GET request line
as a seperate packet then the rest of the data in ~576 byte packet chunks.
Older browsers that enumerate each and every 'Accept: image/gif;' line
for each mime type they know about make huge packets.
We (Yahoo) originally did a delayed accept until the socket became
readable. For the static image servers it worked fairly well (they have no
cookies). However, for the html servers it still was a problem and didn't
have enough of an effect that it was still a problem. HTTPACCEPT fixed it
completely.
As an indication of the kind of difference it makes.. We used to run
apache with a server limit of 1024 processes which it regularly ran into
and maxed out the CPU and started delaying connections in the listen queue.
With HTTPACCEPT these same systems average 4 or 5 active servers are doing
what it used to take 1024 processes to do and went to 90% idle. Things
have changed in our infrastructure since then, but that is a pretty good
indication how much of a HUGE win this is. David Filo doesn't sit around
and write this stuff for fun - it's all to solve real-world problems.
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?20000617020237.0CF2A1CDF>