You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Akins <ba...@web.turner.com> on 2005/09/09 15:42:57 UTC
Re: How long until 2.2
Ian Holsman wrote:
>
> May I suggest you put the following proposal to your management.
>
> cost of devoting a senior engineer for the next month or two to help
> 'field test' apache 2.2 in a high scale environment, identifying and
> submitting patches to 2.2 is Y.
I have been testing 2.1 in our environment. So far, so good. I was
especially testing the prosy stuff (proxy, http, and balancer). Very
good stuff.
The event MPM is much slower in our case.
The new cache still is too slow for our needs. With several of the
patches I have submitted here, we get within about 10% of our in-house
cache. I have integrated allot of the mod_cache stuff into our in-house
cache modules. I suppose our own single-purpose module (reverse
proxy/cache)will always outperform the more general stock mod_cache.
Everything else just works :)
Thanks!
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
Re: How long until 2.2
Posted by Brian Akins <br...@turner.com>.
William A. Rowe, Jr. wrote:
> Quite possibly - generic code is (almost) always a bit less performant.
> But I was curious, are you saying httpd performs at 10% of your custom
> proxy's thoroughput, or simply 10% slower?
I was talking about cache code. Sorry if I wasn't clear.
10% slower with mod_cache (even with patches) than our internal cache.
With small files, it's even worse (30% or so).
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
Re: How long until 2.2
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Brian Akins wrote:
>
> I have been testing 2.1 in our environment. So far, so good. I was
> especially testing the prosy stuff (proxy, http, and balancer). Very
> good stuff.
Good to hear!
> The event MPM is much slower in our case.
We may or may not ship the event MPM. Our new release model has *all*
the code on trunk/. Once the RM and community decide to 'release', we
will also consider dropping specific things.
I have no opinion on whether the event MPM is ready for GA. I'd sure
like to see it shipped in our betas, however! Any observations about
the MPM and specific performance hits I'm sure are appreciated.
> The new cache still is too slow for our needs. With several of the
> patches I have submitted here, we get within about 10% of our in-house
> cache. I have integrated allot of the mod_cache stuff into our in-house
> cache modules. I suppose our own single-purpose module (reverse
> proxy/cache)will always outperform the more general stock mod_cache.
Quite possibly - generic code is (almost) always a bit less performant.
But I was curious, are you saying httpd performs at 10% of your custom
proxy's thoroughput, or simply 10% slower?
Bill
Re: How long until 2.2
Posted by Brian Akins <ba...@web.turner.com>.
Bill Stoddard wrote:
>
> I guess for some definition of "much" I am not suprised. I would expect
> the event MPM to consume more CPU than worker under 'low' workloads (low
> number of concurrent clients)
I was only testing with about 1024 concurrent clients. In production,
we see about 4k.
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
semi-asynchronous leader/followers MPM Re: How long until 2.2
Posted by Brian Pane <br...@apache.org>.
On Sep 9, 2005, at 4:25 PM, Brian Pane wrote:
> This weekend, when I have time to do some more httpd work, I'll do
> a more
> robust hack of the leader MPM within the async-dev branch so that it's
> available for other people to test.
Just committed... This version is a bit slower than the worker MPM.
It does a poll before read on each new connection, which can be
optimized away on platforms where accept(2) doesn't return until
the new connection has data available for reading.
With this latest batch of changes, the leader MPM is converging
toward the design of the event MPM. My goal is to be able to
compare the performance of a central listener thread vs. a
leader/followers thread pool for async MPMs as we add async
write completion.
Brian
Re: How long until 2.2
Posted by Brian Pane <br...@apache.org>.
Colm MacCarthaigh wrote:
>On Fri, Sep 09, 2005 at 04:18:34PM -0400, Bill Stoddard wrote:
>
>
>>I guess for some definition of "much" I am not suprised. I would expect the
>>event MPM to consume more CPU than worker under 'low' workloads (low number
>>of concurrent clients) because it's making more system calls to do the same
>>amount of work. Event should start to show benefits as the number of
>>concurrent connections into the server goes up. That's what I would expect
>>anyway; no idea if the event MPM is sufficiently refined to show any
>>benefit at any workload.
>>
>>
>
>I definitely see speed improvements using the event MPM, probably due to
>the lack of an Accept Mutex. I have to get around to hacking the worker
>MPM to see if that's what it is.
>
>
As part of my recent async R&D, I hacked a copy of the leader/followers MPM
to work with a single, central pollset (like event). It wasn't anywhere
near production
quality--I never got around to implementing tmeouts, for example--but it
was faster
than worker in non-real-world testing (client and server talking to each
other over
Gigabit ethernet.)
This weekend, when I have time to do some more httpd work, I'll do a more
robust hack of the leader MPM within the async-dev branch so that it's
available for other people to test.
Brian
Re: How long until 2.2
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Fri, Sep 09, 2005 at 04:18:34PM -0400, Bill Stoddard wrote:
> I guess for some definition of "much" I am not suprised. I would expect the
> event MPM to consume more CPU than worker under 'low' workloads (low number
> of concurrent clients) because it's making more system calls to do the same
> amount of work. Event should start to show benefits as the number of
> concurrent connections into the server goes up. That's what I would expect
> anyway; no idea if the event MPM is sufficiently refined to show any
> benefit at any workload.
I definitely see speed improvements using the event MPM, probably due to
the lack of an Accept Mutex. I have to get around to hacking the worker
MPM to see if that's what it is.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: How long until 2.2
Posted by Bill Stoddard <bi...@wstoddard.com>.
Brian Akins wrote:
> Ian Holsman wrote:
>
>>
>> May I suggest you put the following proposal to your management.
>>
>> cost of devoting a senior engineer for the next month or two to help
>> 'field test' apache 2.2 in a high scale environment, identifying and
>> submitting patches to 2.2 is Y.
>
>
>
> I have been testing 2.1 in our environment. So far, so good. I was
> especially testing the prosy stuff (proxy, http, and balancer). Very
> good stuff.
>
> The event MPM is much slower in our case.
I guess for some definition of "much" I am not suprised. I would expect the event MPM to consume more CPU than
worker under 'low' workloads (low number of concurrent clients) because it's making more system calls to do
the same amount of work. Event should start to show benefits as the number of concurrent connections into the
server goes up. That's what I would expect anyway; no idea if the event MPM is sufficiently refined to show
any benefit at any workload.
Bill