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:15:36 GMT
One other thing to add here too...that static content is served much faster
than non-static, whatever the case. In terms of bandwidth usage, the more
connections, the higher the bandwidth requirement at all levels, from disk -
to network.

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

> -----Original Message-----
> From: Gonyou, Austin [mailto:austin@coremetrics.com]
> Sent: Monday, July 02, 2001 2:14 PM
> To: 'new-httpd@apache.org'
> Subject: RE: mod_file_cache performance
> 
> 
> 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. 
> 
> -- 
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin@coremetrics.com 
> 
> > -----Original Message-----
> > From: Cliff Woolley [mailto:jwoolley@virginia.edu]
> > Sent: Monday, July 02, 2001 2:06 PM
> > To: Bill Stoddard
> > Cc: new-httpd@apache.org
> > Subject: mod_file_cache performance
> > 
> > 
> > 
> > Hey...
> > 
> >    I've been doing some benchmarks on mod_file_cache, and 
> I'm getting
> > numbers that confuse the hell out of me.  Here's what I've 
> > seen (this is
> > on a RHL 7.1 box with kernel 2.4.3 running on an AMD Athlon 
> > 1.2GHz with
> > 1GB RAM, using /manual/index.html.en as the test file):
> > 
> > 
> > Request for static file:
> > 
> >           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 (WTF?!)
> > MMapFile   80.90 req/s  458.54 KB/s     1978.32 req/s  
> > 11283.72 KB/s (WTF?!)
> > 
> > 
> > Request for server-parsed file:
> > 
> >           No keepalives                 Keepalives
> >           --------------------------    ----------------------------
> > no cache   31.81 req/s  183.68 KB/s      453.38 req/s   2647.38 KB/s
> > CacheFile  87.20 req/s  501.66 KB/s      682.49 req/s   3965.77 KB/s
> > MMapFile  104.17 req/s  599.30 KB/s      674.94 req/s   3925.77 KB/s
> > 
> > 
> > 
> > Clearly there's something screwy going on (as seen in the 
> static file
> > case).  I verified with gdb that sendfile IS being used in 
> the static
> > tests with both the cached and non-cached file handles (I 
> > also examined
> > those apr_file_t's and they looked right).  Maybe a 5KB 
> file should be
> > below the sendfile() threshold on Linux?  That doesn't 
> > explain why it goes
> > SLOWER using sendfile on a cached file handle than it does 
> > using sendfile
> > on a file handle it has to open up on every request.  Maybe it's
> > something with the apr_sendfile() implementation on Linux?  
> > I've looked
> > at it and no problems jump right out at me, though.  I'm stumped.
> > 
> > Anyway, I don't consider this a showstopper for the T&R, 
> > because it serves
> > the requests correctly (one way or another) without 
> segfaulting... but
> > clearly I need to figure out what's going on at some point soon.
> > 
> > (On the other hand, these results tell me that you get a nifty keen
> > speedup by using mod_file_cache to accelerate server-parsed 
> > requests under
> > 2.0 (as I'd hoped), which is something you couldn't really do 
> > in 1.3. :-)
> > 
> > 
> > --Cliff
> > 
> > 
> > --------------------------------------------------------------
> >    Cliff Woolley
> >    cliffwoolley@yahoo.com
> >    Charlottesville, VA
> > 
> 

Mime
View raw message