To get mod_cache/mod_mem_cache (I know little or nothing about mod_disk_cache) really performing competatively against best-of-breed caches will require bypassing output filters (and prebuilding headers) and possibly
Here's some comparative numbers to chew on.
One client and one server on 100Mbps network (cheapy 100Base-T switch); 50 simulated users hitting 7 URLs 100 times with flood (35,000 requests).
mod_disk_cache: Requests: 35000 Time: 40.91 Req/Sec: 856.78 mod_mem_cache: Requests: 35000 Time: 54.90 Req/Sec: 637.81 no cache: Requests: 35000 Time: 54.86 Req/Sec: 638.81 squid: Requests: 35000 Time: 105.35 Req/Sec: 332.25
mod_disk_cache completely filled out the network at ~50% CPU usage. [Can't push through more than ~8MB/sec (~64Mb/sec) without GigE.] mod_mem_cache filled up the CPU but not the network [Poor scaling characteristics. It goes to 100% CPU with just 5 users!] No caching was better CPU-wise (less utilization) than mod_mem_cache [Still not as good network or CPU-wise as mod_disk_cache] squid was really inefficient both CPU and network-wise.
The squid numbers *completely* baffle me. I have to believe I've got something stupid configured in squid (or I did something stupid with flood; but the network traces and truss output convince me otherwise). My squid is using the default RHEL3 installation (Squid Cache: Version 2.5.STABLE3).
squid and httpd are on the same box - I may try to move squid to another box - will see if I have time tomorrow to find a suitable target to move to...
For those playing along at home, I am hitting the following URLs with flood:
/ /apache_pb.gif /manual/ /manual/images/left.gif /manual/images/feather.gif /manual/content-negotiation.html /icons/
HTH. -- justin
