httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From p...@talk21.com
Subject Re: mod_cache: disk layout for vary support
Date Sun, 10 Oct 2010 22:35:08 GMT
----- Original Message ----

From: William A. Rowe Jr. <wrowe@rowe-clan.net>
To: dev@httpd.apache.org
Sent: Sunday, 10 October, 2010 18:09:23
Subject: Re: mod_cache: disk layout for vary support

> On 10/10/2010 10:56 AM, Graham Leggett wrote:
> > 
> > One of the things that needs to be fixed with mod_cache is the support for 
>caching varying
> > responses. In the current cache, we store it as below, as an additional 
>directory tree
> > below the original URL's directory tree. This wastes lots of inodes, and is 
>very expensive
> > to write.
> >
> > What I have in mind is to move the varied content into the main tree, [...]
> > We reuse the same directory structure in the process, and keep the original 
>QSJf2JA.header
> > file indicating that the URL is a varied URL.
>
> +1

Currently the CacheDirLevels and CacheDirLength are also used to calculate 
the path for the varied entities.  What about having separate configuration 
for the vary sub-directory tree?

CacheDirLevels/CacheDirLength will be tuned for storing a huge number of 
URLs.  But how many variants do we expect per URL? A much smaller number.

I'd expect you can safely store all variants in a single subdirectory, i.e. 
VaryCacheDirLevels=0.  That way when it comes to retrieving content, once 
you've parsed the vary file, you've less inodes to deal with before getting 
to the final content.


The directory tree would be:

/tmp/cacheroot/
/tmp/cacheroot//1uq
/tmp/cacheroot//1uq/W@D
/tmp/cacheroot//1uq/W@D/Fok
/tmp/cacheroot//1uq/W@D/Fok/HRU
/tmp/cacheroot//1uq/W@D/Fok/HRU/I62
/tmp/cacheroot//1uq/W@D/Fok/HRU/I62/QSJf2JA.header
/tmp/cacheroot//1uq/W@D/Fok/HRU/I62/QSJf2JA.header.vary
/tmp/cacheroot//1uq/W@D/Fok/HRU/I62/QSJf2JA.header.vary/
thJbK5im1RSzfCKYHquMmA.data
/tmp/cacheroot//1uq/W@D/Fok/HRU/I62/QSJf2JA.header.vary/
thJbK5im1RSzfCKYHquMmA.header

Is that better than starting over from the top level to find the varied 
content?

Thanks,
Paul



      

Mime
View raw message