We are continuing our caching discussions from the past few weeks :
Our goal in the previous few weeks has been to identify caching strategies and technologies. We have now used this knowledge to identify where to invest our focus on improvements. Our conclusion is to go fiercely ahead investigating the following couple of topics further.
1. Reverse proxy caching (Varnish and ESI)
Håkon and Michael will be putting in the effort to research what is possible to do with ESI and VCL. By getting an overview on how we best can utilize Varnish in our applications we can either learn how to configure Varnish ourselves, or inform hosting providers of concrete scenarios which then they can configure for us. It’s worth noting that Varnish has been performing flawlessly on almost every installation we have had to date, so this is an important tool. Our hope is to develop some sensible and helpful best practices for using Varnish with and without ESI.
2. Data caching
Lars and Stefan will be looking into how we can improve our very own AFWCache-mechanisms (AFW is our inhouse, still unreleased framework). We might include MySQL / SQLite data-caching options, as well. Another core topic for them to explore further is whether we’ll be extending the use of APC to also include data caching (as opposed to only opcode caching). In order to decide to use APC for data caching on high performance production environments, we have to learn more about it’s behavior under duress, and we need to know if we can make it degrade gracefully (i.e what happens if APC runs out of memory?)
We will currently not invest more energy in
View and subview caching (application caching) which basically is the slower sibling of Varnish with and without ESI. Although more flexible (you can process cookies), we choose to discard any effort in improving in this area to keep our focus where it need be for the moment. Also our current support for view and subview caching through data caching is performing just fine.
Query Cache – We are requiring query cache to be set to “ON” on every installation. Our conclusion is that this is more than enough for our current needs. We’ll be revisiting the topic of setting query cache to DEMAND and using the /*SQL_CACHE*/ trigger when we are making the new Twitter, or something with a similar requirement for database scaling.
Client caching – We will be refining our guidelines and best practices for setting the correct headers, but we will not invest in the topic of Local Storage (“the new cookie”) as of yet. We’ll wait until the browser support is broader. Local storage is expected to save us a lot of AJAX-callbacks in the future. More on this sometime in the future.
Opcode cache – Having discarded a couple of other candidates, we require APC for PHP on all our installations. Once up and running, it just works without any intervention, so we’ll not be investing any more energy into the topic of opcode caching. We have strengthened our systems setup testing for APC, and we’ll leave it at that.