httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gonyou, Austin" <>
Subject RE: mod_file_cache performance
Date Mon, 02 Jul 2001 21:41:43 GMT
OOh oooh. One other thing to, can you do a top or sar or something and watch
your block reads/writes on the nfs volume? (on both the NFS server and
client) This will tell us the length at which the bottleneck is extending,
either it's on the server side or the client side. I'm asking about that
mainly because there could be things you could do on the server side to
tweak performance rather than client side when mounting. Also, the CPU time
the server takes to answer those requests is a pretty significant problem
I've found. I used to actually have a load ballanced server farm all
connected across NFS which servered up the entire perl libraries on every
request..and that just killed everything one day. All our servers were way
screwed up from that. :) ulimit got killed and CPU time was through the
roof. :) 

Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023

> -----Original Message-----
> From: Cliff Woolley []
> Sent: Monday, July 02, 2001 4:18 PM
> To:
> Subject: Re: mod_file_cache performance
> On Mon, 2 Jul 2001, Bill Stoddard wrote:
> > Hummm... I am hoping that there is a bug in the Apache code 
> cause the
> > alternatives are not pretty...
> >
> > For now, I would suggest completely avoid using 
> CacheFile/sendfile and
> > focus exclusively on why MMapFile is not working.  We know 
> this can be
> > made to work in a process-per-request MPM from our experience with
> > mod_mmap_static in Apache 1.3.  We don't know the same 
> about sendfile
> > or MMapFile in a Linux threaded MPM.  There may be OS problems with
> > sharing an fd (or mmap segment) across multiple threads.  If I get
> > some time, I'll do some tests on my AIX box.
> Another thing to consider (I didn't realize this until after I sent my
> initial message) is that I was serving a file that is on an 
> NFS mounted
> volume physically located on a Solaris box.  That opens up a whole new
> realm of potential bottlenecks.  I'll try again in a few variants: (1)
> with prefork as Austin suggested, and (2) with the file on a 
> local drive
> to eliminate NFS concerns.
> --Cliff
> --------------------------------------------------------------
>    Cliff Woolley
>    Charlottesville, VA

View raw message