Date: Fri, 16 Jun 2000 10:46:18 -0600 (MDT) From: Nate Williams <nate@yogotech.com> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: Peter Wemm <peter@netplex.com.au>, Marc Slemko <marcs@znep.com>, "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: <200006161646.KAA01076@nomad.yogotech.com> In-Reply-To: <200006161640.MAA18110@khavrinen.lcs.mit.edu> References: <marcs@znep.com> <Pine.GSO.4.21.0006152204370.14352-100000@redfish> <20000616095723.6C4771CD7@overcee.netplex.com.au> <200006161640.MAA18110@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. > > I have never seen this. I just did a quick check of the major > clients, and every single one sends the request in a single segment. At my former employer, we were implementing a 'network load balancer' for HTTP traffic, and one of the things that was measured was the fact that literally all client requests fit in a single segment. We were able to fast-path optimize the code to take advantage of this fact since it reduced latency considerable, since we needed the entire segment to make the decision on which machine would be best suited to handle this request. This isn't to say that you wouldn't still get an accept hit upon the initial receipt, and then you would be required to call select again on the new socket and get a hit again when it actually received the request, but that's only two switches, no more. Nate 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?200006161646.KAA01076>