Das Dokument behandelt das Thema Caching im Web, insbesondere die verschiedenen Cache-Layer und die Vorteile von Caching wie schnellere Antwortzeiten und geringerer Rechenaufwand. Es werden verschiedene Caching-Technologien wie Varnish, Memcached, Redis und MongoDB vorgestellt sowie deren Eigenschaften und Anwendungsfälle erläutert. Zudem gibt es praktische Beispiele und Herausforderungen im Zusammenhang mit Cache-Management und Backend-Caching.

1. Cache me if you can
Caching im Web-Umfeld

2. Wer?
● Mario Müller (@xenji / http://www.xenji.com)
● Works @trivago_com
● Likes: @mongodb, @go_nuts
● Andy Grunwald (@andygrunwald / http:
//andygrunwald.com)
● Works @wmdbsystems
● Likes: @blankomat, @devops_borat

3. Um was gehts?
● Speicherung von
○ (mehr oder weniger aufwendig)
berechneten Daten
○ großen Datenmengen
○ wiederkehrenden Daten

4. Layer
● Unter Verwendung von
○ Level 1 Caches
● z. B. XCache oder APC
○ Level 2 Caches
● Memcache, Redis, MongoDB
○ Anderer Caches
● Der Client (Browser, Rich-Client)
● HTTP Caches

5. Ziele
● Zum Erreichen von
○ schnelleren, bzw. garantierten
Antwortzeiten
○ geringerem, bzw. verteiltem
Rechenaufwand
○ geringerer Übertragungsmenge

6. Warum ist Caching denn so geil?
● Weil Rechnen teuer ist
● Weil RAM billig ist
● Weil gecach'te Architekturen besser
skalieren
+ Musketier Prinzip "Einer für alle", einer
Rechnet, alle haben etwas davon.

7. Wir betrachten heute drei Stufen des
Cachings.
st
ue
st
ue
eq
eq
R
st
R
m
ue
em
de
eq
rd
h
R
ac
Vo
Im
N

8. Vor dem Request
Wer nicht rein kommt, macht keinen Dreck

9. Varnish to the rescue!
Requests garnicht erst ankommen lassen...

10. Varnish ist ...
● ein Reverse Proxy Server
● ein HTTP Cache
● verdammt schnell
● Open-Source
● erprobt und bei vielen schon im Einsatz
● die einzige Open-Source Lösung für Edge
Side Includes (ESI)
Symfony2 unterstütz ESI und damit auch
Varnish von Haus aus. Varnish kann aber auch
allen anderen Web Applikationen helfen!

11. Varnish ggn. Apache
Requests: 1.000 - Concurrency: 1
- Apache: 9.97 Requests per Second (RAM:50% CPU:100%)
- Varnish:3003.98 Requests per Second (RAM:50%CPU:5%)
Requests: 1.000 - Concurrency: 10
- Apache: 10.60 Requests per Second (RAM:95% CPU:100%)
- Varnish: 6391.29 Requests per Second (RAM:50% CPU:10%)
Requests:10.000 - Concurrency: 100
- Apache: Absturz
- Varnish: 6179.76 Requests per Second (RAM:55% CPU:15%)
Quelle: http://www.slideshare.net/papst23/n3rd-4-speed

12. Im Request
Andere von der Rechenarbeit profitieren
lassen

13. Backend Caching
Schneller dran kommen...

14. Cache - Types (Auszug)
● Query Result Cache
○ Speichert die reinen DB Ergbnisse von teueren Queries
○ Kann in der Applikation beliebig umher gereicht werden, da es
Rohdaten sind.
● pre-render Cache
○ Vorberechnete Werte, meist auf DB oder Webservice Ergebnissen
basierend
○ Kann meistens nur die direkt verbundene Business - Logik nutzen
● Output Cache
○ Fertiges HTML, JSON, XML, etc.
○ Gut um Last von Servern zu nehmen für Dinge die sich selten ändern
oder explizit neu berechnet werden können

15. Große Herausforderungen
● In welchen Cache Layer soll es?
● Wer oder was sagt an, dass ein Cache
invalide ist?
● Wann wird der Cache neu befüllt?
○ Erste Anfrage nach Invalidierung oder
○ beim Invalidieren oder
○ durch einen Cronjob?
● Wer muss wissen, dass die Daten gecached
sind? (Architektur - Frage)

16. Was macht man beim Backend
Caching ?
● Beten, dass alles so wieder raus kommt, wie
man es rein gesteckt hat
(Problem von verteilten, konkurrierenden Caches)
● Alles was nur irgendwie geht vorberechnen
● Aufpassen,
○ dass das Cache Management nicht die
ursprüngliche Ersparnis aufbraucht
○ dass man auch ohne Cache weiter leben kann.
(Ausfallszenarien)

17. Was gibt es und was kann
man damit machen?
Cache stores

18. Von einer relationalen DB zu ..
● Memcached (Key / Value Store)
○ Level 2 Cache
○ Schnellste wo gibt (meistens)
○ Einfach zu implementieren
○ Reiner In-Memory Store (=> Server weg, Daten
weg)
● Redis
○ Level 2 Cache
○ Wahrscheinlich schneller als Memcached (?)
○ Einfach zu implementieren
○ Mächtiger als Memcached + persistent

19. Von einer relationalen DB zu ..
● MongoDB
○ Eigenständige, mächtige Document DB
○ Kann Level 2 sein oder vollständiger Ersatz
○ Performance abhängig vom Nutzungsszenario
Alle aufgelisteten Server können zusammen
mit einer bestehenden MySQL verwendet
werden, Einige können mehr Logik vertragen
als Andere.

20. Beispieldaten
Wir nehmen uns die "employee database", eine
Demo Datenbank mit ca. 3,2 Mio. Zeilen,

21. Hm, und nu?
● Wir schauen uns Quellcode an
● Wir probieren den Quellcode aus
=> Live Demo

22. Nach dem Request
So viel wie geht beim Client lassen

23. Frontend Caching
Gar nicht erst laden lassen...

24. Einige Zahlen
● Top 1000 Pages: Durchschnittlich >50
Resources per page
● http://www5.mercedes-benz.com/de/
○ 161 Requests
○ 9,48 MB transferred (1. Hit)
○ 1,4 Min @ DSL 700 (1. Hit)
○ 24,09 KB transferred (2. Hit)
○ 5,54 Sek @ DSL 700 (2. Hit)

25. HTTP Standard und der Rest
● Status Codes
● MIME types
● Expires headers
● ETag
● Minify und concat
● gzip

26. Status Codes
● 200 OK
● 204 No Content
● 301 Moved Permanently
● 304 Not Modified
● 404 Not Found
● More codes: https://github.com/joho/7XX-rfc

27. MIME types
● Bekannt aus Film und Fernsehen z.B. HTML
○ <form accept="" enctype="">
○ <script type="">
○ <style type="">
● Server und Client halten "defaults" vor
● Lösung: Vereinheitlichung (via AddType)

28. Expires headers
● Wann läuft eine Ressource ab?
● Grundlage: Standardisierte MIME types
● Far far away? Depends!
ExpiresByType text/html "access plus 0 seconds"
ExpiresByType text/css "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType application/xml "access plus 0 seconds"
ExpiresByType application/json "access plus 0 seconds"

29. Assets Versionierung
● Doof :(
<link rel="stylesheet" type="text/css" href="style.css">
● Gut :|
<link rel="..." type="text/css" href="style.css?131920563">
● Besser :)
<link rel="..." type="text/css" href="style.131920563.css">

30. Das "böse böse " Entity tag
● Server / Client-Kommunikation
● Hash-Wert im HTTP-Header
● Problematisch bei mehreren Servern zur
Auslieferung von Assets (Inode)
● Problematisch bei IIS
○ Filetimestamp:ChangeNumber
● Lösung: Ausschalten ;)

31. Entity tag

32. Entity tag

33. Minify und concat
● Entfernen von "überflüssigen" Zeichen
● Zusammenfassen von Resourcen
● jQuery
○ 247KB, Uncompressed
○ 83KB, Compressed (Google Closure, ohne gzip)
○ 31Kb, Compressed (Google Closure, mit gzip)
● Google Closure Compiler
● YUI Compressor
● Apache mod_pagespeed

34. deflate & gzip
● Server packt die Daten zusammen
● Client entpackt die Daten
● Muss vom Client + Server unterstützt
werden
● Header
○ Accept-Encoding (Client)
○ Content-Encoding (Server)
● Wunderwaffe? Nein! Einsatz Depends!

35. Theorie hin oder her ... Testing?!
● Mozilla: about:cache
● Mozilla Addon: YSlow
● Chrome: Developer Tools

36. Weitere Themen ...
● Cache Manifest
● Local Storage
● SQLite im Browser
● Inline Bilder (base64)
● and many more ...

37. SQLite im Browser
● Kann Cache sein, kann auch mehr sein
● Übersetzungstexte für die Browser Locale
● Applikationseinstellungen bei
Individualisierung
● Der Zustand der Seite beim window.
onunload
● Asset Caching (CSS, JS)

38. Google sagt ...
https://developers.google.com/speed/

39. Tools, Links und Resourcen
● YSlow
● https://github.com/h5bp/html5-boilerplate
● http://danbeam.org/blog/2011/05/06/script-
not-a-type-ical-tag/
● http://www.websiteoptimization.
com/speed/tweak/average-web-page/
● http://www.stevesouders.
com/blog/2008/08/23/revving-filenames-
dont-use-querystring/
● https://github.com/joho/7XX-rfc
● http://developer.yahoo.