Cache Analysis with Heisencache

While front-end  is often where most of the problems in website perceived performance lies, back-end performance is a major issue in Drupal 7, and currently even more so in Drupal 8.

Most backend optimizations focus on improving SQL queries, switching to document-based storage, and globally reducing PHP inefficiencies.

However, experience gathered around large media sites during last year brought evidence of a usually ignored dimension to performance: cache tuning.

While most backend devs are familiar with page and basic data  caching concepts, two common hints to improve performance are regularly "(a) put it in cache (b) use memcached instead of MySQL".  But what if cache costed more than it gains ? And if Memcached turned out to be slower than MySQL ? And popular alternative Redis sometimes less desirable than either ? How do we find out ? APC.php and phpmemcacheadmin are great tools but a) dedicated to one caching storage b) unaware of Drupal-level data.

Heisencache ( https://github.com/FGM/heisencache ) was created for this. This session will explain:

  • the most typical caching problems with Drupal 7 and how to identify them with Heisencache
  • the operation of Heisencache
  • how to write your own Heisencache listener and data-sink plugins for custom analysis

It is an updated version of the session presented last year in Szeged, shortened to remove the implementation parts, of least interest for most of the audience, and updated to keep up with more recent developments and use cases of 2014, especially regarding combination with query analysis.

UPDATE: 2015-04-30

This session prompted znerol to add a wonderful optimization in Authcache : https://www.drupal.org/node/2480741 : what will your own optimization be ?

Slides: 
heisencache-15D17.pdf