httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: svn commit: r360461 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/httpd.h server/protocol.c
Date Tue, 03 Jan 2006 17:37:02 GMT
On Jan 3, 2006, at 12:02 AM, William A. Rowe, Jr. wrote:

> Roy T. Fielding wrote:
>> On Jan 2, 2006, at 2:14 PM, Roy T. Fielding wrote:
>>> Now, if you want to tell me that those changes produced a net
>>> performance benefit on prefork (and thus are applicable to other   
>>> MPMs),
>>> then I am all ears.  I am easily convinced by comparative  
>>> performance
>>> figures when the comparison is meaningful.
>
> lol, of course you choose the non-threaded MPM as a reference,  
> which therefore
> should receive no meaningful performance change.  The difference  
> between an
> async wakeup and a poll result should be null for one socket pool,  
> one process,
> one thread (of course select is a differently ugly beast, and if  
> there were
> a platform that supported async with no poll, I'd laugh.)

You seem to misunderstand me -- if I compare two prefork servers, one
with the change and one without the change, and the one with the change
performs better (by whatever various measures of performance you can  
test),
then that is an argument for making the change regardless of the other
concerns.

If, instead, you say that the change improves the event MPM by 10% and
degrades performance on prefork by 1%, then I am -1 on that change.
Prefork is our workhorse MPM.  The task then is to isolate MPM-specific
changes so that they have no significant impact on the critical path
of our primary MPM, even if that means using #ifdefs.

Alternatively, rewrite the server to remove all MPMs other than
event and then show that the new server is better than our existing
server, and we can adopt that for 3.0.

>> BTW, part of the reason I say that is because I have considered
>> replacing the same code with something that doesn't parse the
>> header fields until the request header/body separator line is
>> seen, since that would allow the entire request header to be parsed
>> in-place for the common case.
>
> Well ... you are using protocol knowledge that will render us http- 
> bound
> when it comes time to efficently bind waka (no crlf delims in a  
> binary format
> protocol, no?) or ftp (pushes a 'greeting' before going back to  
> sleep.)

Well, I am assuming that the MIME header parsing code is in the
protocol-specific part of the server, yes.

....Roy


Mime
View raw message