As we observed before, configuring APC with low memory can be a drag on performance, causing high executing times.
We saw this recently for a client with a large web site on a dedicated server that approached 2bits.com for performance tuning.
They initially had eAccelerator running on Red Hat, but when their hosting provider upgraded the server, eAccelerator refused to run, because of an API change in compatibility and they missed the error messages in Apache's error log.
After doing a full audit of the site we gave them a report with the recommendations, among whichwas to install APC, since they are on newer PHP versions.
Their hosting provider did install APC, but there was no noticeable difference.
Using the apc.php script that is bundled with APC, we were able to pinpoint the problem: poor cache hit ratio:
As you can see, fragmentation is very bad an d we only get the benefitof 16% cache hit ratio. This is because their hosting provider only installed APC, but did not check if it needs tuning or not.
This site has 99 enabled modules and 6 themes, and the default 30MB of APC is not enough.
So, we tuned APC to increase the apc.shm_size parameter to 128MB, and what a difference that made:
We now have 99% cache hit rate, and zero fragmentation.
And we are up to 308 requests per second too.
Server memory usage dropped significantly too, because each Apache process just retrieves the op-code from APC's cache rather than loading and parsing each Drupal module.
If this server was short of memory, we could reduce APC's memory further based on the actual consumption, say to 50MB or so. But it is better to wait for a while and see if the usage pattern changes before doing this kind of adjustment.
原文地址：http://2bits.com/articles/importance-tuning-apc-sites-high-number-drupal-modules.html
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
