Upload
nils-langner
View
24.415
Download
4
Embed Size (px)
DESCRIPTION
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.
Citation preview
Redaktionelle Hochlastseiten
Nils Langner, Gruner + JahrMike Lohmann, Gruner + Jahr ICANS GmbH
Redaktionelle Hochlastseiten 2
Wir.
Nils LangnerQualitätsmanagement und ArchitekturBlogger (www.phphatesme.com)Stolzer Papa
Mike LohmannArchitekturAutor (PHPMagazin)Stolzer Papa
Redaktionelle Hochlastseiten 3
Agenda.
• Redaktionelle Webseiten.
• Infrastruktur und Deployment.
• Günstiger und schneller ausliefern ohne Codeanpassung.
• Nutzung von CDN und ESI.
Redaktionelle Hochlastseiten 4
Gruner + Jahr
Redaktionelle Hochlastseiten 5
Redaktionelle Webseiten
Seiten bestehen aus vielen statischen Einzelkomponenten
„kleine“ Gruppe von Redakteuren
Überschaubare Anzahlneuer Artikel
„Keine“ vom Usererstellten Inhalte
Redaktionelle Hochlastseiten 6
stern.de in Zahlen
160.000.000 Seitenabrufe
Tägliche Stoßzeiten mit Verdreifachung der Anfragen
Sieben Seitenabrufe pro Besuch
stern.tvVerzehnfachung der Anfragen
„Kernarbeitszeiten“7-21 Uhr
Größe der Startseite über 1MB
16.000.000.000 Requests
Redaktionelle Hochlastseiten 7
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 8
Infrastruktur
WebserverCentOS 6.0
(Apache,
PHP 5.3 + Module)
StorageNFSv4
.php, .jpg, .css …
DatenbankMySQL 5.1
Redaktionelle Hochlastseiten 9
Deployment
Integration Stage Live
Betrieb (Systemadmins)
SVN
Webistrano
Dev-(Image)
Entwicklung
Redaktionelle Hochlastseiten 10
„One-Click-Install“
Alle Live-Konfigurationen im SVN
Alle Instanzen (Dev, Integration, Stage und Live) funktionieren mit Live-Konfiguration
• Memcached (Adressen in Dev und Integration auf localhost umgebogen)
• MySQL (ebenfalls auf localhost umgebogen)
Applikation ist sofort nach SVN EXPORT lauffähig
Voraussetzung für Release über Webistrano, da keine Scripte ausgeführt werden können.
Redaktionelle Hochlastseiten 11
Der „Geld spielt keine Rolle“-Ansatz
16.000.000.000 Requests
16.000.000.0001.512.000
10582
31746
RequestsSekunden
Requests pro Sekunde
Requests in Spitzenzeiten
Request: bis 500 MBServer: 16 GB Ram
Maximal 32 gleichzeitige Request
5958 Server
Die Site benötigt 6 Sekunden zum Berechnen!
Redaktionelle Hochlastseiten 12
Klassifizierung der Requests
Dynamische RequestsEin dynamischer Request (HTML) über PHPzusammengefügt.
Statische Requests100 statische Requests auf css-, js- undBilddateien.
Redaktionelle Hochlastseiten 13
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 14
Trennung der Inhalte
160.000.000 Requests
106318
1047631429
dynamische Requests im Schnittdynamische Requests im Peak
statische Requests pro SekundeStatische Requests im Peak
60
Dynamische Inhaltemaximal 32 gleichzeitige Anfragen
15.840.000.000 RequestsStatische Inhalte6000 Anfragen pro Sekunde
6
66 Server
Redaktionelle Hochlastseiten 15
HTTP-Cache-Control-HeaderBrowser-Cache
Anweisungen für CachesWie lange ist ein bestimmter Inhalt gültig?
2 Caching-Strategien
Auslaufen -> ExpiresVerifizieren -> 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
Redaktionelle Hochlastseiten 16
HTTP-Cache-Control-HeaderBrowser-Cache
160.000.000 Requests
dynamische Requests im Schnittdynamische Requests im Peak
statische Requests pro SekundeStatische Requests im Peak
60
Dynamische Inhaltemaximal 32 gleichzeitige Anfragen
11.088.000.000 RequestsStatische Inhalte6000 Anfragen pro Sekunde
4
64 Server
106318
733422000
Redaktionelle Hochlastseiten 17
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 18
HTTP-Accelerator(Funktionsweise)
Beruht auf HTTP; Verben (Methoden) müssen korrekt genutzt werden.
Redaktionelle Hochlastseiten 19
HTTP-Accelerator
• 99.9 % Cache-Hitrate bei statischen Inhalten
• 70% Cache-Hitrate bei dynamischen Inhalten
• stale-if-error
• stale-while-revalidate
Redaktionelle Hochlastseiten 20
HTTP-Accelerator vs. Personalisierung
Lösungen• Stern-Ansatz: Mach‘s nicht
• FTD-Ansatz: Nutze Ajax
• Externer Service (z.B.: Disqus)
• Iframes
• ESI
Redaktionelle Hochlastseiten 21
HTTP-Accelerator
70%
Dynamische Inhaltemaximal 32 gleichzeitige Anfragen11.088.000.000
Requests
Statische Inhalte6000 Anfragen pro Sekunde
160.000.000 Requests
99.9 %
dynamische Requests im Schnittdynamische Requests im Peak
statische Requests pro SekundeStatische Requests im Peak
18
1
19 Server
3296
722
Redaktionelle Hochlastseiten 22
Byte-Code-Cache
$output = „Hello World!“;echo $output;return;
PHP-Code
LexingParsing
ASSIGN !0 ‚Hello+World%21‘ECHO !0RETURN 1ZEND_HANDLE_EXCEPTION
Byte-Code
Execution
PHP-Code
$output = „Hello World!“;echo $output;return; Execution
ASSIGN !0 ‚Hello+World%21‘ECHO !0RETURN 1ZEND_HANDLE_EXCEPTION
Byte-Code
Erfahrungsbericht
• dank APC ist es möglich NFS zu nutzen• Fehler im APC bringen Konzepte durcheinander• CentOS nicht „patchbar“
• Apache nutzt keine „realen“ Pfade• stat0 nicht nutzbar
Redaktionelle Hochlastseiten 23
Byte-Code-Cache
70%
Dynamische Inhaltemaximal 32 gleichzeitige Anfragen11.088.000.000
Requests
Statische Inhalte6000 Anfragen pro Sekunde
160.000.000 Requests
99.9 %
dynamische Requests im Schnittdynamische Requests im Peak
statische Requests pro SekundeStatische Requests im Peak
3296
722
6
1
7 Server
APC
Redaktionelle Hochlastseiten 24
Applikation
Bis hier noch keine Zeile Applikationscode angefasst, trotzdem Faktor 1000 günstiger!
für 70% der User nur noch 150ms für einenSeitenaufruf.
Anmerkung für den Redner: Stehende Ovationen abwarten!
Redaktionelle Hochlastseiten 25
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 26
Memcached als Objectcache
Webservermemcache-
Server
Sharding wird von memcached nativ unterstützt
stern.de
• Keys werden geprefixed
• stern_v191_key1
• Ändern des Präfixes beim
Deployment
Redaktionelle Hochlastseiten 27
Memcached als Objectcache
70% Dynamische Inhaltemaximal 32 gleichzeitige Anfragen
11.088.000.000
Requests
Statische Inhalte6000 Anfragen pro Sekunde
160.000.000 Requests
99.9 %
dynamische Requests im Schnittdynamische Requests im Peak
statische Requests pro SekundeStatische Requests im Peak
3296
722
3
1
4 Server
APC Mem
Mem
Redaktionelle Hochlastseiten 28
sleep
Redaktionelle Hochlastseiten 29
Ü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
4 Server
148.
950
%
Redaktionelle Hochlastseiten 30
stern.tv
•Verzehnfachung der Last• Kein Problem für dynamische Inhalte!
• -> Cache-Hit-Rate erhöht sich drastisch, weil• Last nur für 10 – 20 versch. Seiten
•Problem ist die Anbindung (2Gbit + 1Gbit Redundanz)
•Lösung: CDN
Redaktionelle Hochlastseiten 31
CDN
Normal case
sternTV case
Eigenes Rechenzentrum
Eigenes Rechenzentrum
CDN
Redaktionelle Hochlastseiten 32
ESI(Edge Side Includes)
Gültigkeit: 1 Tag
Gültigkeit: 1 Minute
Gültigkeit: 2 Stunden
Gültigkeit: 5 Minuten
<esi:include src=http://www.stern.de/esi/header onerror="continue"/>
Redaktionelle Hochlastseiten 33
ESI
worst case
average case
Redaktionelle Hochlastseiten 34
ESI bei neon.de
2 Sek.
300 Sek.0 Sek.300 Sek. 0 Sek.
1 Sek.1 Sek.1 Sek.1 Sek.
Cachezeiten Renderzeiten
Redaktionelle Hochlastseiten 35
Framework
SternFramework
• das beste Framework (damals)
• wir können alles anpassen
• wir können alles anpassen
• ESI-Implementierung kostspielig
• keine externen Entwickler „zukaufbar“
• Großer Footprint
• das beste Framework (heute)
• ESI-Unterstützung
• Standard
• Skaliert über Entwickler
• Kleiner Footprint
• Rewrite
Redaktionelle Hochlastseiten 36
Danke.
Fragen
?
Redaktionelle Hochlastseiten 37
Kontaktdaten
Nils Langner
phphatesme
Mike Lohmann
mikelohmann
Redaktionelle Hochlastseiten 38
LinksGruner + Jahr: http://www.guj.de/
ESI (Varnish): https://www.varnish-cache.org/trac/wiki/ESIfeatures
Memcached: http://memcached.org/
Varnish: https://www.varnish-cache.org/
Symfony2: http://www.symfony.com
HTTP-Header: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
ESI-W3: http://www.w3.org/TR/esi-lang
Redaktionelle Hochlastseiten 39
Tools• Bamboo • Jira• Confluence• Cruicible• Fisheye• Greenhopper• phpUnit• pDepend• jMeter• Zend Studio• xDebug• Zend Framework• Symfony2• phpcpd• LiveTest• Webistrano/Capistrano
• PHP_CodeSniffer• PTI• SVN• Git• MySQL• Teamsite• FirstSpirit• jQuery• Memcached• Ant• jsUnit• Vmware• Oracle• Windows7• CentOS
Redaktionelle Hochlastseiten 40
„Release über Webistrano“Applikation liegt auf Stage und Live in Verzeichnis mit Versionsnummer
-> Link auf das Live-Release-Verzeichnis
Memcached-> Values mit Key+Version gespeichert
Config-Cache (Symfony)-> Realpath auf Dateien
Neues Release = neues Verzeichnis-> altes Release immer noch vorhanden (auch Caches)
Livegang ist atomar (Linkwechsel)-> Rollback sehr schnell möglich
! Noch keine Lösung für Strukturänderungen an Datenbanken!
=> Noch nie vorgekommen