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.

1. Redaktionelle Hochlastseiten Nils Langner, Gruner + Jahr Mike Lohmann, Gruner + Jahr ICANS GmbH

2. Wir. Mike Lohmann Architektur Autor (PHPMagazin) Stolzer Papa Nils Langner Qualitätsmanagement und Architektur Blogger (www.phphatesme.com) Stolzer Papa Redaktionelle Hochlastseiten 2

4. Infrastruktur und Deployment.

5. Günstiger und schneller ausliefern ohne Codeanpassung.

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

10. Infrastruktur Storage NFSv4 .php, .jpg, .css… Webserver CentOS 6.0 (Apache, PHP 5.3 + Module) Datenbank MySQL 5.1 Redaktionelle Hochlastseiten 8

11. Deployment Betrieb (Systemadmins) Entwicklung Stage Live Integration Webistrano Dev-(Image) SVN Redaktionelle Hochlastseiten 9

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

21. HTTP-Accelerator(Funktionsweise) Beruht auf HTTP; Verben (Methoden) müssenkorrektgenutztwerden. Redaktionelle Hochlastseiten 18

23. 70% Cache-Hitrate bei dynamischen Inhalten

24. stale-if-error

25. stale-while-revalidateRedaktionelle Hochlastseiten 19

27. FTD-Ansatz: Nutze Ajax

28. Externer Service (z.B.: Disqus)

29. Iframes

30. ESIRedaktionelle Hochlastseiten 20

31. HTTP-Accelerator 70% 160.000.000 Requests Dynamische Inhalte maximal 32 gleichzeitige Anfragen 11.088.000.000 Requests Statische Inhalte 6000 Anfragen pro Sekunde 99.9 % Redaktionelle Hochlastseiten 21 dynamische Requests im Schnitt dynamische Requests im Peak statische Requests pro Sekunde Statische Requests im Peak 32 96 7 22 18 1 19 Server

33. Fehler im APC bringen Konzepte durcheinander

34. CentOS nicht „patchbar“

35. Apache nutzt keine „realen“ Pfade

36. stat0 nicht nutzbarPHP-Code Byte-Code $output = „Hello World!“; echo $output; return; ASSIGN !0 ‚Hello+World%21‘ ECHO !0 RETURN 1 ZEND_HANDLE_EXCEPTION Execution Redaktionelle Hochlastseiten 22

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

41. stern_v191_key1

42. Ändern des Präfixes beim DeploymentSharding wird von memcached nativ unterstützt Redaktionelle Hochlastseiten 26

43. Memcached als Objectcache Redaktionelle Hochlastseiten 27 APC Mem 70% Dynamische Inhalte maximal 32 gleichzeitige Anfragen 160.000.000 Requests 11.088.000.000 Requests Mem 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 3 1 4 Server

44. sleep Redaktionelle Hochlastseiten 28

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 %

47. Kein Problem für dynamische Inhalte!

48. -> Cache-Hit-Rate erhöht sich drastisch, weil

49. Last nur für 10 – 20 versch. Seiten

50. Problem ist die Anbindung (2Gbit + 1Gbit Redundanz)

52. ESI(Edge Side Includes) Gültigkeit: 1 Tag <esi:include src=http://www.stern.de/esi/header onerror="continue"/> Gültigkeit: 1 Minute Gültigkeit: 2 Stunden Gültigkeit: 5 Minuten Redaktionelle Hochlastseiten 32

53. ESI worstcase averagecase Redaktionelle Hochlastseiten 33

54. ESI bei neon.de Cachezeiten Renderzeiten 300 Sek. 0 Sek. 300 Sek. 0 Sek. 1 Sek. 1 Sek. 1 Sek. 1 Sek. 2 Sek. Redaktionelle Hochlastseiten 34

56. wir können alles anpassen

57. wir können alles anpassen

58. ESI-Implementierung kostspielig

59. keine externen Entwickler „zukaufbar“

60. Großer Footprint

61. das beste Framework (heute)

62. ESI-Unterstützung

63. Standard

64. Skaliert über Entwickler

65. Kleiner Footprint

66. RewriteRedaktionelle Hochlastseiten 35

67. Danke. ? Fragen Redaktionelle Hochlastseiten 36

68. Kontaktdaten Nils Langner nils.langner@phmlabs.com phphatesme Mike Lohmann mike.lohmann@phmlabs.com mikelohmann Redaktionelle Hochlastseiten 37

69. Links Redaktionelle Hochlastseiten 38 Gruner + 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

71. Jira

72. Confluence

73. Cruicible

74. Fisheye

75. Greenhopper

76. phpUnit

77. pDepend

78. jMeter

79. Zend Studio

80. xDebug

81. Zend Framework

82. Symfony2

83. phpcpd

84. LiveTest

85. Webistrano/Capistrano

86. PHP_CodeSniffer

87. PTI

88. SVN

89. Git

90. MySQL

91. Teamsite

92. FirstSpirit

93. jQuery

94. Memcached

95. Ant

96. jsUnit

97. Vmware

98. Oracle

99. Windows7