From owner-cvs-all Fri Jun 16 2:57:30 2000 Delivered-To: cvs-all@freebsd.org Received: from overcee.netplex.com.au (peter1.corp.yahoo.com [208.48.107.4]) by hub.freebsd.org (Postfix) with ESMTP id 6781837BE1F; Fri, 16 Jun 2000 02:57:24 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 6C4771CD7; Fri, 16 Jun 2000 02:57:23 -0700 (PDT) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Marc Slemko Cc: "Daniel O'Connor" , "Daniel C. Sobral" , Alfred Perlstein , Nate Williams , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_socket.c uipc_socket2.c src/sy In-Reply-To: Message from Marc Slemko of "Thu, 15 Jun 2000 22:10:24 PDT." Date: Fri, 16 Jun 2000 02:57:23 -0700 From: Peter Wemm Message-Id: <20000616095723.6C4771CD7@overcee.netplex.com.au> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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