Re: performance of ap_poll (was Re: [PATCH] Compiler warning + 64-bitAIX cleanup in dexter mpm

[Greg Ames <gr...@raleigh.ibm.com>]

rbb@covalent.net wrote:
> 
> >
> > There is a noticable difference in ApacheBench's performance between 2.0
> > and 1.3.
> > ab2.0 uses ap_poll(); ab1.3 uses select().
> >
> 
> Regardless, even though ap_poll is slower than poll, do we really care in
> this case?  We are talking about a child thread that is waiting on a pipe
> and a few sockets.  When the poll call gets woken up, the thread is going
> to spend much more time actually serving the request.  Making this one
> call to poll slower is just not going to destroy our performance on the
> dexter MPM.
> 
You may be right.  ab looks like it's using ap_poll to check for
readability on established connections, so it could be dealing with more
sockets (up to 10 in my test).  Also, it is probably updating the list
of interesting sockets much more often. 

But on the other hand, in my test we had the entire pathlength of the
2.0 prefork server plus the costs of the socket calls added to the
pathlength of whichever ab I was using....

I'll measure the new dexter vs. the old, once I figure out why OS/390
won't build any more  :-(   

Greg