Date: Fri, 16 Jun 2000 11:25:31 -0700 From: John-Mark Gurney <gurney_j@efn.org> To: Marc Slemko <marcs@znep.com> Cc: 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: <20000616112531.12083@hydrogen.funkthat.com> In-Reply-To: <Pine.GSO.4.21.0006152200020.14352-100000@redfish>; from Marc Slemko on Thu, Jun 15, 2000 at 10:02:54PM -0700 References: <20000615161246.37298@hydrogen.funkthat.com> <Pine.GSO.4.21.0006152200020.14352-100000@redfish>
next in thread | previous in thread | raw e-mail | index | archive | help
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 like a > > > HTTP request header already in the socketbuffer. This ought to reduce > > > 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... > 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... 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... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "Thank God I'm an atheist, that'd just be confusing." -- cmc 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?20000616112531.12083>