httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <>
Subject Re: svn commit: r360461 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/httpd.h server/protocol.c
Date Mon, 02 Jan 2006 22:44:20 GMT

On Jan 2, 2006, at 2:14 PM, Roy T. Fielding wrote:

> On Jan 2, 2006, at 1:37 PM, Brian Pane wrote:
>> "Significantly faster than prefork" has never been a litmus test for
>> assessing new features, and I'm -1 for adding it now.  A reasonable
>> technical metric for validating the async changes would  
>> "significantly
>> more scalable than the 2.2 Event MPM" or "memory footprint
>> competitive with IIS/Zeus/phttpd/one's-competitive-benchmark-of- 
>> choice."
> Those aren't features.  They are properties of the resulting system
> assuming all goes well.
>> The bit about degrading the rest of the server is a wonderful sound
>> bite, but we need to engineer the httpd based on data, not FUD.
> I said leave it on the async branch until you have data.  You moved
> it to trunk before you've even implemented the async part, which I
> think is wrong because the way you implemented it damages the
> performance of prefork and needlessly creates an incompatible MMN

You have yet to present any data backing up the assertion that
it "damages the performance of prefork."  (Repeating the claim
doesn't count as a proof.)  Having looked at the compiler's
inlining of the code that's been factored into separate functions,
I'm rather skeptical of the claim.

The "incompatible MMN" point is puzzling, to say the least.  As the
4th MMN change in the past quarter, this was by no means an
unusual event.  And on an unreleased development codeline,
the impact to production sites and 3rd party module developers
is near zero.


View raw message