In this email to the ILUG Webdev list I pondered the effect of deleting the cache used by PHP Accelerator on our Apache webserver.
In my ramblings on my blog I (very?) occasionally post something useful.
We use PHP Accelerator( http://www.php-accelerator.co.uk/index.php ) at work and last week I played around with tuning our webserver: linkWe saw a dramatic increase in traffic but I wasn’t sure which of the ideas I tried had affected our server so much!
Yesterday I deleted the PHP Accelerator cached files, and lo and behold, we hit another spike in traffic!“Remember I did some tuning of our server at work? Well, traffic has returned to normal again, but I was told this is a quiet time in the futures market right now. As an exercise I deleted the php Accelerator cached files again and I am seeing another big jump in requests served!
It might pay to remove those files on a daily basis!”I setup a cron job to remove the phpa files in the morning and if I see the same level of traffic today I may set it up to delete the cached files on an hourly basis tomorrow. I expect the traffic to the site to be slightly less today than yesterday simply because the cached files were deleted much earlier on in the day (4am) so by the time our server gets busy there’ll be a larger cache.
And, shock, horror, I might even try it without the cache at all!
Donncha.
—
ILUG Web Development
http://mail.linux.ie/mailman/listinfo/webdev/
Well, I can confidently say that deleting the cache does improve performance. In further discussion with Kae on the issue I guessed that:
- All php files are being cached, probably using the URL of the request as a key to the cached file. This isn’t useful in a very dynamic site.
- The cache directories can become very large with many thousands of files in one directory. That makes it much harder for the operating system to scan through the file list. Different filesystems handle this better than others.
- Once the cache is deleted, filename traversal of the cache is faster and
core
include files are quickly cached again.
It’s worth using the cache despite the obvious cache problems as it makes Smarty templates much faster and we have a lot of shared code that benefits from the caching.
I’m deleting the cache every hour now and expect to see a marked improvement in the web server logs and adviews!
It sounds like it might be worthwhile to try modifying the caching code so that it splits the cached files into multiple subdirectories. Perhaps by getting an MD5 or SHA1 hash of the URI, taking the first character, and using that as a subdirectory name. That should at least break things down to handle only 1/16th as many files per directory. And if you need to break it down more than that, you can use two characters, and go two dirs deep.
So for example:
MD5 (“http://example.com/foo.php”) = 722f59840354db62331730d58c4bc055
Which could give you something like “…/cache/7/2/SomeCacheFileNameForThisURI”
If large file tables are indeed part of the problem, this should make a difference.
I already did that, as much as I could anyway.
I don’t have the source code to the php cache we’re using (see the link above – there’s a faq about it) so I can’t break it into smaller directory slices.
Deleting the cache has worked wonders for performance however and I’m surprised I haven’t seen the same recommendation anywhere else!
Have you tried mmcache? I’ve found it much better than phpa.
did some body modified mmcache for spliting cache files in multiple directories? if yes, can you please email me the source code ?
Thanks alot.
Just make sure your you split your cache directory into seperate directories according to virtual host.