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