unfortunately I haven’t found a good solution:( I’ve just been either caching or deflating based on the file type, but not doing both.

CacheIgnoreHeaders Age Date Host User-Agent Accept Accept-Language Accept-Encoding Accept-Charset Keep-Alive Connection Cookie Cache-Control Vary (this indicates that I am not a power user of linux

Anyway, I was wondering if you have found a solution to this. We have an apache(2.2.11)/mod_jk/jboss(4.2.2) setup wherein we want to cache non-user specific xml files (like http://www.tennisearth.com/widget/displayLiveScores.htm) requested from jboss to be cached for 10 seconds. To take care of the fact that the last modified time of these files might be only a few milliseconds in past, we had even set CacheLastModifiedFactor to 10000.
I guess there is some other header that we should ignore that should do the trick. We do not want to remove mod_deflate.

I’m glad that the CacheDirLevel change has helped some!

How do you know what the total number of possible option values is for my website? Did you try setting the option and then peek at the cookie? Even so, that doesn’t cover the number of possible Vary values, since there is also the id cookie which is set for users – and that can have a huge number of permutations since it’s stored as an encrypted hash digest (i.e. long string of gibberish). So you’d need to multiple the opts permutations by the id permutations – and even then, that just gives you the number of possible versions for just one file. There are hundreds of thousands of dynamically generated pages on the site. It wouldn’t work to just have the caching on the home page (to handle slashdottings) since they can link to any interesting page – e.g. a particularly funny pic in a journal, or a day page that talks about something interesting etc etc ad infinitum. It’s really endless, so I need to cache all dynamically generated content, really.

Anyway, I tried setting CacheDirLevels to 2 rather than 3, and already I think I see an improvement. I do have more files now in each of the level 2 subdirs, but at present it only seems to be of the order of 10 or so, which is nothing much – you only see problems when you go to tens of thousands of files in a single directory, as I recall. Even then, you could enable dir_index for the partition to get the hash tree for filename lookup (but I don’t want to do that since it tends to require dodgy multiple reboots with e2fscks and I’ve read that it can cause problems on some systems).

As it stands now, I have the following for htcacheclean:

htcacheclean -i -t -n -d60 -p/var/cache/www -l1000M

And this morning, I can do a du -hs on the cache directory, it seems to complete in a few seconds (much better). I’ll have to retest randomly, since it’s possible that the directory tree just happened to be mostly in cache – it’s much more telling to do it cold, so the disks actually have to be read. It’s interesting that htcacheclean doesn’t seem to take into account the full size of the directories, since du -hs gives me a size of 1.9GB, almost twice the requested size for htcacheclean. I guess htcacheclean maybe only looks at the actual filesize of the content, and just ignores the size of the directories themselves (which are files, and take up some space). Maybe it also doesn’t take into account the header files, I dunno.

I thought about increasing CacheDirLength to 2, because that would result in an even broader and more shallow directory structure. But looking at the characters it seems to use for the current directories, a-z, A-Z, 0-9, _ and @, then that would give us 64^2 = 4096 possible subdirs in each directory level. I think it’s probably better the way it is right now – something on the order of tens of files is certainly going to be better than thousands in terms of lookup performance.

I do still see little spikes in iowait (using munin to monitor), but I’ll leave this for a day or two to see how it pans out over time. Maybe just removing one level of directories (CacheDirLevels from 3 to 2) is enough to make the difference here – after all, it’s effectively reducing a power function by 1, which is exponential in terms of the possible number of subdirs. We’ll see…

Thanks,

Neil

The mv and purge later plan isn’t a bad one. If you try it, let me know. Or you could just not do any cleanup.

I’ve found that a more shallow dir structure performs much better, even though it means more files per dir. I don’t know about you, but I was ending up with very few files in the actual end-node directories, but there were a ton of directories. The Apache recommendations don’t seem to apply if you’re using any sort of Vary header. Reducing the directory tree size by a few orders of magnitude only led a hundred files/dir or so, which is very manageable. So that might be worth a try.

Another thing you could do, if you’re mostly worried about a slashdotting, is to only cache the index page, and let the rest be served from perl. That would keep your cache very small, and solve your primary concern. Or you could cache the index page via mod_mem_cache or something.

I mostly use mod_disk_cache to keep my J2EE apps from having to serve out static files from the war repeatedly, so our uses are a bit different.