httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gonyou, Austin" <aus...@coremetrics.com>
Subject RE: mod_file_cache performance
Date Mon, 02 Jul 2001 19:26:50 GMT
I see..so you're saying the cache file should be "the highest" perhaps? 
If that's the case, then it seems that there is something possibly related
to accessing the cache which is causing you a bottleneck?
Perhaps this is indicitive of some further MPM issues. What MPM did you use
to do this test? Threaded?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com 

> -----Original Message-----
> From: Cliff Woolley [mailto:cliffwoolley@yahoo.com]
> Sent: Monday, July 02, 2001 2:20 PM
> To: new-httpd@apache.org
> Subject: RE: mod_file_cache performance
> 
> 
> On Mon, 2 Jul 2001, Gonyou, Austin wrote:
> 
> > >
> > >           No keepalives                 Keepalives
> > >           --------------------------    
> ----------------------------
> > > no cache  118.98 req/s  676.92 KB/s     2280.06 req/s  
> 13053.79 KB/s
> > > CacheFile  90.19 req/s  511.21 KB/s     2181.21 req/s  
> 12440.95 KB/s
> > > MMapFile   80.90 req/s  458.54 KB/s     1978.32 req/s  
> 11283.72 KB/s
> >
> > Seen here, this is a common theme when benchmarking. The 
> less the connection
> > numbers are, there is a direct proportion to the kb/second 
> that will be seen
> > as through put. This is a good thing, because if it went up 
> as you scaled
> > down, you'd have the inverse affect. This is not preferred 
> of course.
> 
> I think one of us has missed the other's point (it's entirely possible
> that I've missed yours).  I think what you're saying is that it makes
> sense for the KB/s to decrease when the req/s decreases, as 
> opposed to the
> inverse effect.  Yes, I agree, that makes sense.  That's not what I'm
> worried about.  The problem I'm seeing is that ALL of the 
> numbers across
> the row should be HIGHER for the CacheFile case than for the 
> "no cache"
> case.  That they're not means there's something wrong with the caching
> system.  =-)
> 
> --Cliff
> 
> 
> --------------------------------------------------------------
>    Cliff Woolley
>    cliffwoolley@yahoo.com
>    Charlottesville, VA
> 
> 

Mime
View raw message