How long until 2.2

["Akins, Brian" <Br...@turner.com>]

As I sit here debugging our home grown proxy code for 2.0, I wonder how long
until 2.2?  We wrote our own proxy because the cool 2.1 stuff was not out at
the time.  The new proxy stuff would be wonderful for us, but noone wants to
run alpha code in production.  (However, we are quick to run homegrown
stuff...)

So, please, I be you -- give us 2.2 ;)

Thanks.

 

Re: How long until 2.2

[Olaf van der Spek <ol...@gmail.com>]

On 8/9/05, Ian Holsman <li...@holsman.net> wrote:
> 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.

Just wondering, when will Win32 binaries of 2.1/2.2 be available for testing?

Re: How long until 2.2

[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

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

[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

[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

[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

[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

[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

Re: How long until 2.2

[Brian Akins <ba...@web.turner.com>]

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

[Ian Holsman <li...@holsman.net>]

Akins, Brian wrote:
> As I sit here debugging our home grown proxy code for 2.0, I wonder how long
> until 2.2?  We wrote our own proxy because the cool 2.1 stuff was not out at
> the time.  The new proxy stuff would be wonderful for us, but noone wants to
> run alpha code in production.  (However, we are quick to run homegrown
> stuff...)
> 
> So, please, I be you -- give us 2.2 ;)
> 

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.

This should be considered a sunk cost. you will have to perform this 
test now, or in 2-3 months time when we officially release it as 2.2.

The only advantage of waiting is that you hope someone else will find
the same problems as your team would.

The disadvantages of waiting
- your changes you testing find might not be able to be applied to the 
main core, as altering a 'production' system takes more checks and 
paperwork than a developmental one. so you will be stuck in the same 
situation you are now.. maintaining a patched up apache.

- If you get organized now, you might be able to distribute the testing 
phase with other large companies in a similar situation to you. This 
might reduce the cost of 'Y', or allow you to concentrate on the 
features you care more about, knowing that other people will be doing 
other parts of the testing as well. (ie.. sharing the cost of 'Y' over 
multiple companies).

so to summarize.. get your testing team into the 2.1 code now, and you 
will have a more stable 2.2 when it comes out, and you might even 
convince your management that version numbers don't mean squat in a open 
source world.

Cheers
Ian

> Thanks.
> 
>  
> 

Re: How long until 2.2

[Paul Querna <ch...@force-elite.com>]

Akins, Brian wrote:
> As I sit here debugging our home grown proxy code for 2.0, I wonder how long
> until 2.2?  We wrote our own proxy because the cool 2.1 stuff was not out at
> the time.  The new proxy stuff would be wonderful for us, but noone wants to
> run alpha code in production.  (However, we are quick to run homegrown
> stuff...)

I ran out of time post-apache-con to do another 2.1-alpha/beta, and
currently I am waiting for an APR 1.2.0 release, to fix several big bugs
that 2.1.6-alpha pointed out.

I welcome anyone else who wants to RM more 2.1 releases to help get to
2.2 sooner.

-Paul