stern.de ist mit ca. 170 000 000 Seitenabrufen im Monat eine der höchstfrequentierten Webangebote Deutschlands. In Spitzen, wie zum Beispiel zu einer Stern-TV-Sendung, wird die Last auf den Systemen für einige Zeit mehr als verdoppelt. Um diesen sprunghaften Anstieg der Last kosteneffizient abzubilden, bedarf es einer flexiblen System- und Softwarearchitektur. Es wird gezeigt, wie diese Anforderungen an eine redaktionelle Hochlastwebsite sowohl in der Infrastruktur als auch in der Software abgebildet werden und es werden dazugehörende Herausforderungen skizziert. Behandelt werden unter anderem: PaaS, Gateway-, Object- und Byte-Code-Cache, ESI, Content Delivery Networks, Bottlenecks und Load Balancing.
2. Wir. Mike Lohmann Architektur Autor (PHPMagazin) Stolzer Papa Nils Langner Qualitätsmanagement und Architektur Blogger (www.phphatesme.com) Stolzer Papa Redaktionelle Hochlastseiten 2
7. Redaktionelle Webseiten „Keine“ vom User erstellten Inhalte „kleine“ Gruppe von Redakteuren Überschaubare Anzahl neuer Artikel Seiten bestehen aus vielen statischen Einzelkomponenten Redaktionelle Hochlastseiten 5
8. stern.de in Zahlen Tägliche Stoßzeiten mit Verdreifachung der Anfragen stern.tv Verzehnfachung der Anfragen Größe der Startseite über1MB 160.000.000 Seitenabrufe „Kernarbeitszeiten“ 7-21 Uhr 16.000.000.000 Requests Sieben Seitenabrufe pro Besuch Redaktionelle Hochlastseiten 6
9. Ziele des Vortrags Wir kochen auch nur mit Wasser. Performanz ist wichtig. Einfach ist wichtiger. „Gut-genug“-Prinzip: Lösung folgt Anforderung. Praxiserfahrungen vermitteln. Funky Technologien. Frontend-Performance. Redaktionelle Hochlastseiten 7
13. MySQL (ebenfalls auf localhost umgebogen)Redaktionelle Hochlastseiten 10 Applikation ist sofort nach SVN EXPORT lauffähig Voraussetzung für Release über Webistrano, da keine Scripte ausgeführt werden können.
14. Der „Geld spielt keine Rolle“-Ansatz Request: bis 500 MB Server: 16 GB Ram Maximal 32 gleichzeitige Request 16.000.000.000 Requests 16.000.000.000 1.512.000 10582 31746 Requests Sekunden Requests pro Sekunde Requests in Spitzenzeiten 5958 Server Die Site benötigt 6 Sekunden zum Berechnen! Redaktionelle Hochlastseiten 11
15. Klassifizierung der Requests Dynamische Requests Ein dynamischer Request (HTML)über PHP zusammengefügt. Statische Requests 100 statische Requests auf css-, js- und Bilddateien. Redaktionelle Hochlastseiten 12
16. Trennung der Inhalte 3 Sub-Domains für verschiede statische Inhalte s1.stern.de => Bilder, CSS, JS zur Applikation gehörig d1.stern.de => Bilder, von Usern erstellt c1.stern.de => Bilder, CSS, JS, zu einem Inhalt gehörig und über das CMS erstellt Config-Datei zur Konfiguration der Sub-Domain für die verschiedenen Inhalte 1 Domain für dynamische Inhalte (von PHP prozessiert) stern.de => HTML, XML, RSS, JSON Redaktionelle Hochlastseiten 13
17. Trennung der Inhalte 160.000.000 Requests Dynamische Inhalte maximal 32 gleichzeitige Anfragen 15.840.000.000 Requests Statische Inhalte 6000 Anfragen pro Sekunde 106 318 10476 31429 dynamische Requests im Schnitt dynamische Requests im Peak statische Requests pro Sekunde Statische Requests im Peak 60 6 66 Server Redaktionelle Hochlastseiten 14
18. HTTP-Cache-Control-HeaderBrowser-Cache Redaktionelle Hochlastseiten 15 Anweisungen für Caches Wie lange ist ein bestimmter Inhalt gültig? 2 Caching-Strategien Auslaufen -> Expires Verifizieren -> If-Modified-Since, ETag s1.stern.de = Expires („unendlich“, Invalidierung über ?id=<hash>) c1.stern.de und d1.stern.de = Expires (begrenzt) + Validation stern.de = Expires (abhängig vom Alter des Artikels) Beispiel
19. HTTP-Cache-Control-Header Browser-Cache Redaktionelle Hochlastseiten 16 160.000.000 Requests Dynamische Inhalte maximal 32 gleichzeitige Anfragen 11.088.000.000 Requests Statische Inhalte 6000 Anfragen pro Sekunde dynamische Requests im Schnitt dynamische Requests im Peak statische Requests pro Sekunde Statische Requests im Peak 60 106 318 7334 22000 4 64 Server
20. HTTP-Accelerator(Web-Cache, Gateway-Cache, Reverse Proxy) „ Varnish Cache is an open source, state of the art web application accelerator. You install it on your web server and it makes your website fly. “ Redaktionelle Hochlastseiten 17
37. Byte-Code-Cache Redaktionelle Hochlastseiten 23 APC 70% 160.000.000 Requests Dynamische Inhalte maximal 32 gleichzeitige Anfragen 11.088.000.000 Requests Statische Inhalte 6000 Anfragen pro Sekunde 99.9 % dynamische Requests im Schnitt dynamische Requests im Peak statische Requests pro Sekunde Statische Requests im Peak 32 96 7 22 6 1 7 Server
38. Applikation Bis hier noch keine Zeile Applikationscode angefasst, trotzdem Faktor 1000 günstiger! für 70% der User nur noch 150ms für einen Seitenaufruf. Anmerkung für den Redner: Stehende Ovationen abwarten! Redaktionelle Hochlastseiten 24
39. „ Free & open source, high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load. “ Redaktionelle Hochlastseiten 25
45. Übersicht „Geld spielte keine Rolle“-Ansatz Trennung der Inhalte nach Typ Cache-Header HTTP-Accelerator Byte-Code-Cache Memcache 5958 Server 66 Server 64 Server 19 Server 7 Server 4Server Redaktionelle Hochlastseiten 29 148.950 %