Redaktionelle Hochlastwebseiten am Beispiel von stern.de

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


Agenda.

• Redaktionelle Webseiten.

• Infrastruktur und Deployment.

• Günstiger und schneller ausliefern ohne Codeanpassung.

• Nutzung von CDN und ESI.


Gruner + Jahr


Redaktionelle Webseiten

Seiten bestehen aus vielen statischen Einzelkomponenten

„kleine“ Gruppe von Redakteuren

Überschaubare Anzahlneuer Artikel

„Keine“ vom Usererstellten Inhalte


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


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.


Infrastruktur

WebserverCentOS 6.0

(Apache,

PHP 5.3 + Module)

StorageNFSv4

.php, .jpg, .css …

DatenbankMySQL 5.1


Deployment

Integration Stage Live

Betrieb (Systemadmins)

SVN

Webistrano

Dev-(Image)

Entwicklung


„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.


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!


Klassifizierung der Requests

Dynamische RequestsEin dynamischer Request (HTML) über PHPzusammengefügt.

Statische Requests100 statische Requests auf css-, js- undBilddateien.


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


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

http://www.elbcoast.net/?p=77


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

http://d1.stern.de/bilder/stern_5/fotografie/2011/KW28/Katharina_Hesse_Bangkok/Katharina_Hesse_Bangkok_420_maxpane_150_100_middle_top.jpg

http://it-republik.de/php/artikel/Website-Optimierung-per-Caching-3313.html


HTTP-Cache-Control-HeaderBrowser-Cache




60

Dynamische Inhaltemaximal 32 gleichzeitige Anfragen

11.088.000.000 RequestsStatische Inhalte6000 Anfragen pro Sekunde

4

64 Server

106318

733422000

http://www.elbcoast.net/?p=77


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.

„

“


HTTP-Accelerator(Funktionsweise)

Beruht auf HTTP; Verben (Methoden) müssen korrekt genutzt werden.


HTTP-Accelerator

• 99.9 % Cache-Hitrate bei statischen Inhalten

• 70% Cache-Hitrate bei dynamischen Inhalten

• stale-if-error

• stale-while-revalidate


HTTP-Accelerator vs. Personalisierung

Lösungen• Stern-Ansatz: Mach‘s nicht

• FTD-Ansatz: Nutze Ajax

• Externer Service (z.B.: Disqus)

• Iframes

• ESI


HTTP-Accelerator

70%

Dynamische Inhaltemaximal 32 gleichzeitige Anfragen11.088.000.000

Requests

Statische Inhalte6000 Anfragen pro Sekunde


99.9 %



18

1

19 Server

3296

722


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


Byte-Code-Cache

70%

Dynamische Inhaltemaximal 32 gleichzeitige Anfragen11.088.000.000

Requests



99.9 %



3296

722

6

1

7 Server

APC


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!


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.

„

“


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


Memcached als Objectcache

70% Dynamische Inhaltemaximal 32 gleichzeitige Anfragen

11.088.000.000

Requests



99.9 %



3296

722

3

1

4 Server

APC Mem

Mem


sleep


Ü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

%


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


CDN

Normal case

sternTV case

Eigenes Rechenzentrum

Eigenes Rechenzentrum

CDN


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"/>


ESI

worst case

average case


ESI bei neon.de

2 Sek.

300 Sek.0 Sek.300 Sek. 0 Sek.

1 Sek.1 Sek.1 Sek.1 Sek.

Cachezeiten Renderzeiten


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


Danke.

Fragen

?


Kontaktdaten

Nils Langner

[email protected]

phphatesme

Mike Lohmann

[email protected]

mikelohmann


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

http://www.guj.de/

http://www.guj.de/

http://www.guj.de/

https://www.varnish-cache.org/trac/wiki/ESIfeatures



http://memcached.org/

http://memcached.org/

https://www.varnish-cache.org/



http://www.symfony.com/

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html



http://www.w3.org/TR/esi-lang




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


„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

Technology

Redaktionelle Hochlastwebseiten am Beispiel von stern.de