httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@cnet.com>
Subject Re: mod_file_cache performance
Date Mon, 02 Jul 2001 23:10:36 GMT
On 02 Jul 2001 15:52:05 -0700, dean gaudet wrote:
> is this across loopback?
> 
> if so then it's useless for performance tuning/measurement.  you gotta use
> a real network, and a beefy enough client to get any meaningful results.
> 
> or is it a single 100baseT segment?  if so then this is too little network
> to give meaningful results as well.  unless you optimise something other
> than "r/s" or "bytes/s" -- study the idle CPU for example.  idle CPU
> becomes a much more useful metric when you aren't maxing out the system.

I have a sun E4500 8 cpu machine, running Solaris 8, attached to
WebAvalance box which I can run some tests on for you tomorrow. (it is
said it can do ~ 10,000 GETS/second)

What I'll need from you is your configure config script.

..Ian

> 
> that said, you might want to use lmbench <ftp://ftp.bitmover.com/lmbench/>
> to study what file open times are like under linux.  they're pretty damn
> small.  linux's dcache kicks a lot of ass... and in the end, userland
> caching of stuff like this just means you're duplicating efforts.  that
> means a waste of L2, which will have a non-linear decrease on your
> performance.
> 
> but i'm just guessing.
> 
> -dean
> 
> On Mon, 2 Jul 2001, Cliff Woolley wrote:
> 
> >
> > 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