apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: pools + ap_pfree
Date Sat, 02 Mar 2002 23:39:00 GMT
'Justin Erenkrantz' wrote:

>On Fri, Mar 01, 2002 at 10:19:17PM -0600, Emery Berger wrote:
>>High-performance was indeed one of my design goals. What tests would you
>>consider authoritative? I've been using static page loads, driven by a
>>process on the same machine. This was the best way I found to really
>>stress pool allocation. I'd be happy to run any other tests you could
>I believe that we found that mod_include (multiple #includes) or
>mod_autoindex request (lots of subreqs) really stress the pool code.
>I think Brian had one test case where ~30 pools were created and
>destroyed during that one mod_include'd request.  -- justin

Right, mod_include was where the performance differences in different
pool implementations became really apparent.

To answer Emery's original question about other recommended performance
tests, here's some background info:

I've been testing mod_include performance mostly with artificial
benchmark files that do things like this:

<!--#include virtual="1.shtml" -->
<!--#include virtual="1.shtml" -->
<!--#include virtual="1.shtml" -->
<!--#include virtual="1.shtml" -->
<!--#include virtual="1.shtml" -->

where "1.shtml" is a 1-byte file (so that network transfer time
doesn't overshadow the time spent in the httpd code).

Ian H. has been testing with pages from news.com that do a total
of about 10 includes, using a stress testing setup that provides
data on CPU and memory utilization under high load.

For testing pool stuff, a couple of techniques that we've found to
be valuable are:

  * Look at httpd CPU utilization, not just throughput.

  * For really useful comparisons of the CPU utilization of
    different implementations, run with a good profiler to
    get precise measurements of the time spent in apr_palloc().
    We've used mostly Quantify for this, because it provides
    CPU utilization measurements down to the basic block level--
    good for finding out where the bottlenecks are within a


View raw message