httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: svn commit: r468373 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_cache.c modules/cache/mod_cache.h modules/cache/mod_disk_cache.c modules/cache/mod_disk_cache.h modules/cache/mod_mem_cache.c
Date Fri, 27 Oct 2006 20:24:51 GMT
Davi Arnaut wrote:

> But that's a corner case. There is no reason in doing this for small
> files (common case). For example, in a enterprise grade server memory is
> cheap and permanent storage is slow and expensive.

If permanent storage is slow and expensive, what on earth is the admin 
doing trying to turn on a disk cache?

However luckily though the typical modern OS helps by RAM caching common 
disk access, the argument has been made here before that a disk cache 
gives same or better performance than the memory cache.

Please don't forget that mod_cache, by design, is a generic RFC2616 
caching proxy bolted onto the frontend of the webserver, and that means 
you can cache virtually any well behaved application - from mod_perl, to 
CGI, to mod_python, mod_proxy, whatever.

And also don't forget that compared to the speed at which a webserver 
can generate data, the typical client is many orders of maginitude 
slower at swallowing that data. So your big expensive mod_perl, CGI, 
mod_python, etc sits around waiting for the client to get on with it and 
download the response, using resources better spent elsewhere.

A very common use case is for a caching proxy is to take the load off an 
expensive application server, and usually this is deployed as a separate 
piece of kit in front of the webserver. With mod_cache, you can offload 
this inside the server itself, which simplifies your setup.

In short, this is not a corner case.

>> Also, httpd seems to be faster delivering data by sendfile than 
>> delivering data from memory buckets. That's more of a performance bug 
>> in httpd though.
> It's not all httpd fault.  Sendfile avoids memory copying/context
> switches/etc behind the scenes (in the kernel) because it "talks"
> directly to the underlying file system. When you have the memory already
> in user space there isn't much that you can do, the kernel has to copy
> it..etc.

Exactly - another strong argument to make sure that when you turn on the 
disk cache, you serve the network off the disk cache.


View raw message