Date: Fri, 16 Jun 2000 08:46:39 -0700 (PDT) From: Marc Slemko <marcs@znep.com> To: Peter Wemm <peter@netplex.com.au> Cc: 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: <Pine.GSO.4.21.0006160836240.25194-100000@redfish> In-Reply-To: <20000616095723.6C4771CD7@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 16 Jun 2000, Peter Wemm wrote: > 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. Very often, all HTTP servers do is IO. All IO is is a little bit of user code inbetween a bunch of context switches. How many context switches can a modern box running FreeBSD do? How many HTTP requests per second would have to be processed before one or two more context switches per request had a significant impact? > > 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. Umh... huh? I don't know of any commonly used browsers that send a typical HTTP request in more than one segment. Can you show me the tcpdump output from such an example? I do not believe that one or two extra context switches is all that significant and, if it is, then just implement something like NT's AcceptEx that waits for the first segment to be available for read(), no need to go to the extent of trying to magically parse the content you get. I do not understand why the http specific code is necessary. AcceptEx is still a hack, but a more generally useful and less bad-magical hack. > > 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. Again, huh? I am quite familiar with the HTTP protcol and with the details of how browsers implement it (particularily the interactions between HTTP and TCP) and nowhere does it require this, nor do browsers do what you describe. If browsers do things in a really stupid way, then they should be fixed. However, in this case, they don't do things that way. > > 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. I'm afraid that your understanding is incorrect. Perhaps you could double check what you heard or someone could show some actual numbers? I expect that perhaps somewhere along the line, a "order of magnitude improvement with all these changes" was heard as "an order of magnitude with this one change". Thanks. 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?Pine.GSO.4.21.0006160836240.25194-100000>