httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davi Arnaut <d...@haxent.com.br>
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 17:41:18 GMT
Niklas Edmundsson wrote:
> On Fri, 27 Oct 2006, Graham Leggett wrote:
> 
>>>> Err. We had the data in memory, we are going to read it back from disk
>>>> again just in order to not block ? That's nonsense.
>>> Agreed.
>> Please explain.
>>
>> This is a disk cache. Why would you write expensive bucket data to cache,
>> and then expensive bucket data to the network?
>>
>> That's plain stupid.
> 
> And when you have a file backend, you want to hit your disk cache and 
> not the backend when delivering data to a client. People might think 
> that this doesn't matter, but for large files, especially larger than 
> RAM in your machine, you usually go disk-bound without much help from 
> the OS disk cache.

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.

> 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.

--
Davi Arnaut


Mime
View raw message