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:13:41 GMT
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