On Sat, Sep 08, 2001 at 11:33:48AM -0700, Justin Erenkrantz wrote:
[snip]
> - Completely remove threaded MPM and replace it with worker. I do
> not think that the current threaded MPM can work (due to discussions
> held on this list previously). The worker MPM (which Aaron has been
> making progress towards) should act as a replacement MPM. I know
> that Aaron has some patches that he has tested that make it faster
> than prefork. I look forward to seeing those patches make it in
> and fully tested.
To keep everyone informed as to the status of the worker MPM (this would
be good stuff to put in the STATUS, maybe I'll provide a patch). I have
three implementations of worker that each do things a little differently.
I will be trying to acquire access to a large N-way SMP box in the near
future to test the scalability attributes of each variation. Under an
artificial workload generated from flood, I have seen at least one of my
implementations perform on par with the perfork MPM. There are still
some bugs to be worked out of the worker (It's having trouble with the
MaxClients directive right now), but I should have these figured out
soon enough. If we are able to produce a beta in the next week, I'll
shoot for a stable worker MPM by the next beta.
> - Get the APR lock situation straightened out. This means converting
> the old lock API to the new one. (This probably means that APR
> needs to at least be beta by the time we release httpd as GA - other
> than the locks, I don't see that as a major problem. I don't want
> to have any major API changes after we hit GA - the lock API is a
> fairly major API in APR.)
The new lock API itself is pretty straightened out, and we've been committing
bit-sized chunks over the last week or so. I expect the full API to be
commited in the next week, and maybe another week or so to get a full
implementation on the other non-UNIX platforms (as well as some good testing).
At that point we can do each of two things: 1) port the old API to use the
new one, and 2) port httpd to the new API.
[cut out a bunch of stuff that would be well suited for a STATUS]
> - I would like to see performance with Apache 2.0 equal or surpass
> the performance of Apache 1.3. However, I'm not entirely sure
> that will happen before we can release (if you want to do so in
> 45 days as some have suggested). Given that that may not be the
> case, I'd like it to be as close as possible. In the last few
> weeks, we've definitely made strides towards improving our
> performance (especially in mod_include - thanks to Brian and Ian).
> In the subsequent point releases, we can continue to address the
> overall performance and attempt to make 2.1 faster than 1.3.
> However, if 2.0 isn't faster than Apache 1.3, I wonder how many
> people will adopt it (however, most sites are bandwidth limited,
> so I'm not sure if this is a concern). Therefore, I think we
> need to come to a consensus about our take on the performance of
> Apache 2.0 relative to Apache 1.3. Is it a requirement that
> Apache 2.0 must be as fast as Apache 1.3 before we hit GA?
This brings up a good point: What is satisfactory in terms of performance
and features to release a 2.0 GA from this group? How do we answer
questions like "how much faster is it?" and "how well does it scale?" and
"what new features do I have to look forward to?" To most people I don't
think the last question will be at all obvious. The work from Brian,
Ian, Justin, OtherBill, etc has done wonders for performance, but we're
still not (by my calculations) anywhere near as fast as 1.3. How good
is good enough? Some guidance here may help us newbies.
[snip snip]
-aaron
