httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Burry" <dbu...@tagnet.org>
Subject Re: mod_mem_cache bad for large/busy files (Was: [PATCH] remove some mutex locks in the worker MPM)
Date Fri, 03 Jan 2003 05:21:08 GMT

----- Original Message -----
From: "Brian Pane" <brian.pane@cnet.com>
Sent: Thursday, January 02, 2003 2:19 PM
>
> For large files, I'd anticipate that mod_cache wouldn't provide much
benefit
> at all.  If you characterize the cost of delivering a file as
>
>    time_to_stat_and_open_and_close +
time_to_transfer_from_memory_to_network
>
> mod_mem_cache can help reduce the first term but not the second.  For
small
> files, the first term is significant, so it makes sense to try to optimize
> away the stat/open/close with an in-httpd cache.  But for large files,
where
> the second term is much larger than the first, mod_mem_cache doesn't
> necessarily
> have an advantage.

Unless... of course, you're requesting the same file dozens of times per
second (i.e. high hundreds of concurrent downloads per machine, because it
takes a few minutes for most people to get the file).... then caching it in
memory can help, because your disk drive would sit there thrashing
otherwise.  If you don't have gig ethernet don't even worry you won't see
the problem really, ethernet will be your bottleneck.  What we're trying to
do is get close to maxing out a gig ethernet with these large files without
the machine dying...

>  And it has at least three disadvantages that I can
> think of:
>   1. With mod_mem_cache, you can't use sendfile(2) to send the content.
>      If your kernel does zero-copy on sendfile but not on writev, it
>      could be faster to deliver a file instead of a cached copy.

Memory is always faster than a spinning disk.  It should be possible to make
a memory cache that's faster than the disk, and uses the same amount of
space as disk too.

>   2. And as long as mod_mem_cache maintains a separate cache per worker
>      process, it will use memory less efficiently than the filesystem
>      cache.

yes, that is definitely a problem.  good that mod_file_cache does not have
this problem, but it has other file list maintainability problems.

>   3. On a cache miss, mod_mem_cache needs to read the file in order to
>      cache it.  By default, it uses mmap/munmap to do this.  We've seen
>      mutex contention problems in munmap on high-volume Solaris servers.

sounds familiar...

> What sort of results do you get if you bypass mod_cache and just rely on
> the Unix filesystem cache to keep large files in memory?

Not sure how to configure that so that it will use a few hundred megs to
cache often-accessed large files... but I could ask around here to more
solaris-knowledgable people...

Dave


Mime
View raw message