httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: Httpd 3.0 or something else
Date Wed, 11 Nov 2009 12:45:01 GMT

On Nov 11, 2009, at 6:09 AM, Graham Leggett wrote:

> William A. Rowe Jr. wrote:
>>> - Supporting prefork as httpd does now; and
>> I'm very happy to see prefork die it's timely death.
>> Let's go about working out where out-of-process magic happens.
>> Gated, single threaded handlers may be sensible in some cases.
>> But for the core server it makes async worthless, and supporting
>> both digs us deeper into the bad-old-days of the 1.3 codebase.
> I disagree strongly, for a number of reasons.
> The first is that in our experience of a very high traffic collection of
> websites, the more "hops" you have, the more performance starts to suck,
> with the added complication that you run the risk of bumping your head
> into the ceiling of filehandle limits, and other issues.
> If you move from "httpd-prefork" to "httpd-something proxied to
> random-appserver-X-doing-prefork-for-you" you aren't removing prefork -
> you just moving it somewhere else and adding an extra hop.
> You're also making it more complicated, and more complicated means less
> reliable.
> People like to harp on about how they want "speed speed speed". Right up
> to the point where it first starts becoming unreliable. At that point
> they suddenly start crying "reliable reliable reliable".
> Apache httpd does lots of things right.
> We must resist the temptation to throw out what we do right, while we
> try move forward fixing what we do wrong.

I must say I agree. Having a method to avoid the 1:1 mapping of request/resp
to a specific "entity" (worker or thread) is nice, but that solves a
different problem than that solved by prefork. I'd like for us to solve
the one while also being able to continue to solve the other. When, for
example, nginx works, it works well. When it doesn't, it is simply
completely unsuitable. I'd like for us to continue to avoid that being
the case for httpd.

View raw message