1. HIGH PERFORMANCE
SITES WITH DRUPAL
AND CACHE CONTROL
MODULE
Janne Salo
Senior Developer

2. Outline
 Exove in brief
 What is Cache Control and how does it work?
 Easy case: Jatkoaika.com
 Anonymous users, high read/write ratio
 Hard case: Demi.fi
 Autheticated users, low read/write ratio
 Different case: Tekla Campus
 Using Cache Control with a CDN
 Discussion

3. Exove in Brief
ExoveisaleadingNorthernEuropeancompanyspecialisinginopen
sourcewebservicesdesignanddevelopment.
WehelpcompaniesconductbetterbusinessontheInternet
throughbest-of-breedpersonnelandsolutions.
Quickfacts:
 Founded2006
 About60people
 Servedmorethan120clients
 OfficesinFinland,Estonia,andtheUK
 CEOJanneKalliola
 Meetusatbooth38

4. WHAT IS CACHE CONTROL
AND HOW DOES IT WORK?
drupal.org/project/cache_control

5. What is Cache Control?
 Module for integrating your site with Varnish or
some other HTTP cache
 Sets appropriate Cache-Control headers in HTTP
responses from Drupal.
 Supports also content purging
 Automatic purges for e.g. node updates, hooks for
custom purges
 Comes with an admin UI for selecting cacheable
menu router paths and a VCLfile for Varnish

6. How does it work?
 Varnish checks if requested page is cached
 If it is, Varnish sends it to user’s browser (also for
authenticated users!)
 If it isn’t, pass the request to Drupal, execute the page
load as anonymous user and cache the response in
Varnish
 Process the response in user’s browser
 For anonymous users, show the page as is
 For authenticated users, generate personalized parts in
anAJAX back-end (get_components) and inject the
results on the page

7. “Personalized content?”
 You can enable Cache Control for any Drupal
block – the block will be generated for
authenticated users in the get_components
back-end
 Using Cache Control’sAPI, you can “tag” any
part of the page to be generated for in the
get_components back-end

8. Benefits of Cache Control
 Only the needed parts are loaded: The back-
end is significantly less burdened
 All personalized parts of the are loaded in a
single request
 The user is given something to look at while the
hard parts of the page are being loaded – the
site feels faster

9. What’s the catch?
 Building high-performance sites is a complex
matter. Cache Control is not a magic bullet to
solve all your performance issues
 While developing, you have to “think in Cache
Control” or you’ll be in a world of trouble
 You will most likely end up writing at least some
custom code and spending time wondering why the
site behaves differently when Cache Control is
enabled

10. What about ESI?
 ESI (Edge Side Includes) is a partial loading
technique supported by Varnish and some CDNs,
e.g.Akamai
 It basically makes Varnish do the partial page
loading
 Varnish first fetches the common version from cache
 Then it looks though the page to see any ESI markup
 Then it loads all the ESI marked parts of the page from
cache or from Drupal

11. How does Cache Control
differ from ESI?
 ESI needs to wait until the whole page is loaded
before giving anything to the user
 ESI loads all the portions of the page (still in D7,
this might change in D8) in separate HTTP
requests, thus burdening the server with even
more bootstraps than without any cache

12. THE EASY CASE

13. Jatkoaika.com
 Jatkoaika.com is the leading ice hockey site in
Finland
 200 000 unique visitors and 1.6M page loads per
week
 Page loads in Drupal are almost exclusively
done by anonymous users
 Content is read a lot more often than
written, making the site an ideal use case for
Cache Control

15. Jatkoaika.com – Setup
 Drupal, MySQL, SOLR, memcached, Varnish –
all running on one server
 Cache Control enabled for all content pages
(nodes, taxonomy terms, front page) with
different TTLs – no custom code required
 Server loads are minimal

16. THE HARD CASE

17. Demi.fi
 Demi.fi is the community around the Demi
magazine, targeted to teenage girls
 2.8M weekly page views
 Most page loads done by authenticated users
 1 300 – 1 500 logged-in users during busy hours
 The users generate a lot of content (forum
posts, comments, etc.)
 Keeping the cache up to date is a challenge

19. Demi.fi – Setup
 Drupal, MySQL (Percona), SOLR, MongoDB, nginx
+ php-fpm, memcached, Varnish – all running on
(almost) one server
 Cache Control enabled for almost all user-facing
pages and someAJAX backends as well
 Alot of personalized components per page, putting strain
on the get_components back-end
 Quite a lot custom code required in making the site
compatible and triggering cache purges when needed.
 Server loads are significant but mostly tolerable

20. Demi.fi – Strategy
 Avoid Drupal bootstrap and theming
 Cache Control: try to keep as much content in
Varnish cache as possible
 Fast JSON-based backends for data that changes
often (e.g. forum topic listings): offload theming to
users’browsers. Use Cache Control to cache the
results with shortTTL(30 secs or so)
 Use fast storage: SOLR for Views, MongoDB for
field storage, memcached for cache.
 Get a good sysadmin

21. Demi.fi – Lessons Learned
 Cache Control’s get_components back-end needs
to be fast
 Cache Control now supports MongoDB as storage
backend
 Cache Control’s front-end needs to be fast
 We had to rethink how to manipulate the page that has
lots of personalized content
 Continuous cache purging can also be a
performance issue
 Varnish 3.0-style bans take up a lot of resources, use
purges (2.0-style bans) instead

22. Demi.fi – More Lessons
 Building high-performance sites is hard, and it gets
harder if you don’t take performance into account
from the very beginning
 This includes design: be aware of the performance cost of
displaying a certain piece of content on a page, identify
and mitigate potential performance killers
 Cache Control is far from perfect and doesn’t alone
solve your problems
 Ironing out small glitches with e.g. cache purging
can be a lot of work
–

23. THE DIFFERENT CASE

24. Tekla Campus
 Tekla Campus is an e-learning tool and
community for engineering and construction
students
 Users come from all over the world
 Almost all of them are authenticated
 Not that much user-generated content,
moderate amount of personalized content for
logged-in users

26. Tekla Campus – Setup
 The site is hosted in Finland, but user base is
spread all over the world
 To mitigate latency, we needed a CDN solution
 Turns out Fastly CDN uses Varnish, so we
decided to give it a go
 Cache Control plays nicely with Fastly, even
cache purges work out of the box
 Fastly even allows you to upload your own VCL

27. SUMMARY

28. Summary
 Cache Control is a module for integrating your
site with e.g. Varnish. It works for both
anonymous and authenticated users
 It can help make your site a lot faster
 It can be easy or hard, depending on the complexity
of your site
 You can also use it to help with geographical
distribution of your site

29. THANK YOU!
WHAT DID YOU
THINK?
Locate this session at the
DrupalCon Prague website:
http://prague2013.drupal.org/schedule
Click the “Take the survey”
link