We host splendidtable.org and a few other sites at a well known Drupal provider that uses Amazon EC2 to host sites. We found A. we were hitting the limits of our server capacity in terms of # of php workers available, and B. that the cost of adding additional server capacity was cost prohibitive for us so I set about to make everything more efficient ie .. long cache times. The idea being that most content does not change once it is created so why waste cpu cycles on recreating it all the time?
So I went about setting cache times for page cache and external cache to a full day. We have Varnish and Memcache running (and even Akamai in front of that but Akamai still needs tuning). Additionally I installed cache actions modules and set the home page and other landing pages (which are either views or panels) to cache actions's permanent cache.
This site really only gets content updates a few times a week so I added a custom module that implements hook_node_insert and update that clears the views and panels caches, runs cache_clear_all for the updated node and landing pages, and sends custom purge requests to Varnish for nodes and landing pages whenever content is updated.
Last I installed Elysia cron and set node and system cron hooks to run just once per week.
My assumption was that a full day of cache times would increase Varnish hit rates dramatically but I have only seen a small increase so far. (Prior to this external page cache or Varnish was set to last one hour).
Here are the numbers this was implemented on 8/19 around mid-day
Date Domain Requests Uncached Drupal Varnish Cache Hit Ratio 8/20/13 www.splendidtable.org 149,381 44,343 25,205 83.13 8/19/13 www.splendidtable.org 211,830 58,505 39,331 81.43 8/11/13 www.splendidtable.org 184,868 67,084 40,233 78.24 8/6/13 www.splendidtable.org 152,832 52,348 29,391 80.77
So I don't have much of a sample size yet but it looks like this strategy is only slightly better set Varnish to last for an hour.
The traffic for this site is about 25% hitting the home page or landing pages and the rest kind of a long tail spread across stories and recipes on the site.
What do you think? Have I chosen a caching strategy that really isn't much better than just cache for an hour? Should I try for an even longer cache times? is there something else I am failing to take into consideration or misunderstanding? Maybe I should concentrate on caching at the Akamia level? I also think this may understate the effectiveness of memcache as some request may go to the Drupal level but skip hitting Mysql.
Really my first take was 80% cache hit rate is pretty good so just add more RAM so we can have more php processes but thats cost prohibitive under our current hosting arrangement.
Comments
Purge+Expire
For mostly static (just high traffic) site you should consider https://drupal.org/project/purge along with https://drupal.org/project/expire with as long Varnish cache TTL as possible. Then you could avoid over-engineering (and breaking eventually) all Drupal internal caching logic.
Its pretty clear you will
Its pretty clear you will need to diagnose what kind of cache misses you are getting:
I remember there were issues
I remember there were issues and patches specifically to fix Acquia Cloud compatibility, but I see there are reports about new problems in the queue, too bad: https://drupal.org/node/1994048
At any rate, I would suggest to dig with the help of something like (even free) New Relic to find if there is anything to improve on the site's code or config level and if this is really just not enough PHP workers issue, then maybe test the site's copy performance on some VPS where you could get Barracuda (BOA) quickly installed and tuned for comparison.
Happy to help with this issue
Hi ghankstef,
Taking a little look at the splendidtable.org site I’ve noticed some ways we can both optimise the site whilst also addressing some of the problems you’re experiencing.
Predominantly, I’d like to take some time to go over some of the other multisites and see how each is affecting the server as a whole as some overall optimisation for another site may help splendidtable.org; especially if the other multisites are taking up a substantial amount of server resources.
Regarding Purge/Expire modules, there is an Acquia implementation that may prove useful to you by way of the Acquia Purge module. This will allow you to implement active purging on your sites and provide the ability to flush varnish on the balancers. Whilst this is a sandbox module, it's something we've tested with a number of customers and is used on production sites without any issue.
I’ll be sending you a ticket to look at the performance of this site and to see if we can provide you a few more tips that’ll bring your cache hitrate a bit higher and reduce the amount of memory required, on average, for each request.
Thanks,
Adam Malone | Client Advisor | Acquia