apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <I...@cnet.com>
Subject Re: Pools, possible replacement, WAS: RE: [Fwd: brianp patch Quantify results]
Date Sat, 25 Aug 2001 05:36:11 GMT
On Fri, 2001-08-24 at 17:40, Justin Erenkrantz wrote:
> On Fri, Aug 24, 2001 at 05:21:11PM -0700, Marc Slemko wrote:
> > On Fri, 24 Aug 2001, Justin Erenkrantz wrote:
> > 
instead of looking at raw network thoughput look at heavy users of
pools, CPU utilization, and truss/prof output.
and compare these results with standard pool, and with brians patch.

I would concentrate more on getting 100 rps going through in the
following conditions:

* standard file no parsing (ie .. sendfile)
* mod include with 2 includes (header/footer) (as this REALLY uses
pools heavily)
* Keep-alives

I'll fire up the 8-way box on monday and compare sanders and brians
pool code against the 'stock' pool and see what I can see.

There was also the pool replay code I wrote a while back which could be
used to compare pool allocaters, as well as dreieds memory tests for the
SMS.

BTW can flood simulate a steady # of requests being attempted per
second? 
or does it just fire up N threads/processes and whack away.
( check out http://www.cs.rice.edu/CS/Systems/Web-measurement/ for more
info)
> > > If you have the backplane (my guess would be Gigabit Ethernet) to
> > 
> > Well, or just a less powerful server.  The goal isn't the best raw
> > numbers, the goal is comparison.  Granted, that comparison can be
> > different on various sized machines (eg. SMP vs. not, etc.).
> 
> Well, part of the problem is that Sander's pool optimization is 
> intended to benefit MP boxes.  It adds thread-local free-lists - so
> the benefit is probably only noticable on MP boxes under load.
> 
> The problem is that I can't get enough out of our network (with
> the URLs I hit) to see if it improves the performance.  I will
> try to adjust the URLs I hit to see if I can move the bottleneck
> back to the CPU.  
> 
> Any suggestions here?  -- justin
-- 
Ian Holsman
Performance Measurement & Analysis
CNET Networks    -    415 364-8608

Mime
View raw message