You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2000/06/22 21:57:53 UTC
performance of ap_poll (was Re: [PATCH] Compiler warning + 64-bit
AIX cleanup in dexter mpm
>
> There is a noticable difference in ApacheBench's performance between 2.0
> and 1.3.
> ab2.0 uses ap_poll(); ab1.3 uses select().
>
> +--------+--------+--------+
> | | ab2.0 | ab1.3 |
> +--------+--------+--------+
> | run 1 | 867 | 1156 |
> +--------+--------+--------+
> | run 2 | 869 | 1155 |
> +--------+--------+--------+
> | run 3 | 870 | 1156 |
> +--------+--------+--------+
> | run 4 | 878 | 1159 |
> +--------+--------+--------+
> | avg | 871.0 | 1156.5 |
> +--------+--------+--------+
>
> ab1.3 is 33% faster than ab2.0 in this config. No, I haven't proven
> that it's ap_poll() yet, but it's my prime suspect - the rest of ab is
> pretty simple stuff.
It probably is ap_poll. There is a very simple reason for this. ap_poll
has never been optimized for performance. There are two fixes for
it. 1) Re-write ap_poll with an eye towards performance (needs to be
done at some point anyway) 2) Try using the ap_poll logic that uses
select instead of poll under the covers.
The select logic is much cleaner and more performance aware IMHO. I tend
to think that we should be using the select logic first until somebody
gets around to grabbing the poll logic from FreeBSD and just throwing it
into APR.
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.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: performance of ap_poll (was Re: [PATCH] Compiler warning + 64-bitAIX
cleanup in dexter mpm
Posted by 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
Re: performance of ap_poll (was Re: [PATCH] Compiler warning +
64-bitAIX cleanup in dexter mpm
Posted by rb...@covalent.net.
On Tue, 27 Jun 2000, Tony Finch wrote:
> rbb@covalent.net wrote:
> >
> >2) Take the poll implementation from FreeBSD and convert it to use
> >ap_file_t's. This should perform much better than the current
> >implementation.
>
> Um, FreeBSD's poll is implemented in the kernel so I don't see how it
> could be of any use to a userland application.
I never actually looked at FreeBSD's poll, but I hoped it would be
userland. Oh well. That means we just have to invest a bit more
time/effort to optimize the current ap_poll.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: performance of ap_poll (was Re: [PATCH] Compiler warning +
64-bitAIX cleanup in dexter mpm
Posted by Tony Finch <do...@dotat.at>.
rbb@covalent.net wrote:
>
>2) Take the poll implementation from FreeBSD and convert it to use
>ap_file_t's. This should perform much better than the current
>implementation.
Um, FreeBSD's poll is implemented in the kernel so I don't see how it
could be of any use to a userland application.
Tony.
--
f.a.n.finch fanf@covalent.net dot@dotat.at
302 a hearty slap on your mud-flap
Re: performance of ap_poll (was Re: [PATCH] Compiler warning +
64-bitAIX cleanup in dexter mpm
Posted by rb...@covalent.net.
> > > 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.
>
> For a single listener, there is negligible degradation with ap_poll. It
> becomes more noticable as you add listeners, but still isn't too bad:
As I said before, there are two ways to fix this. Neither has been done
yet, because performance has not been something the APR developers have
been concerned with, yet.
1) Try the select based implementation. It is much cleaner and should
perform better.
2) Take the poll implementation from FreeBSD and convert it to use
ap_file_t's. This should perform much better than the current
implementation.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: performance of ap_poll (was Re: [PATCH] Compiler warning + 64-bitAIX
cleanup in dexter mpm
Posted by 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.
For a single listener, there is negligible degradation with ap_poll. It
becomes more noticable as you add listeners, but still isn't too bad:
+-------------+------------+------------+-------------+
| | old Dexter | new Dexter | degradation |
| | w/poll | w/ap_poll | |
+-------------+------------+------------+-------------+
| 1 listener | 1104.0 | 1090.0 | 1.3% |
+-------------+------------+------------+-------------+
| 100 | | | |
| listeners | 826.6 | 804.3 | 6.7% |
+-------------+------------+------------+-------------+
Greg