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 21:37:36 GMT
On Jan 2, 2006, at 11:52 AM, Roy T. Fielding wrote:

>> It would be feasible to build up the pending request in a structure
>> other than the request_rec, so that ap_read_async_request() can
>> operate on, say, an ap_partial_request_t instead of a request_rec.
>> My preference so far, though, has been to leave the responsibility
>> for knowing how to parse request headers encapsulated within
>> the request_rec and its associated "methods."
> Maybe you should just keep those changes on the async branch for now.
> The rest of the server cannot be allowed to degrade just because you
> want to introduce a new MPM.  After the async branch is proven to be
> significantly faster than prefork, then we can evaluate whether or
> not the additional complications are worth it.

"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."

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.


View raw message