0
Redaktionelle Hochlastseiten<br />Nils Langner, Gruner + Jahr<br />Mike Lohmann, Gruner + Jahr ICANS GmbH<br />
Wir.<br />Mike Lohmann<br />Architektur<br />Autor (PHPMagazin)<br />Stolzer Papa<br />Nils Langner<br />Qualitätsmanageme...
Agenda.<br />Redaktionelle Hochlastseiten<br />3<br /><ul><li>Redaktionelle Webseiten.
Infrastruktur und Deployment.
Günstiger und schneller ausliefern ohne Codeanpassung.
Nutzung von CDN und ESI.</li></li></ul><li>Gruner + Jahr<br />Redaktionelle Hochlastseiten<br />4<br />
Redaktionelle Webseiten<br />„Keine“ vom User<br />erstellten Inhalte<br />„kleine“ Gruppe <br />von Redakteuren<br />Über...
stern.de in Zahlen<br />Tägliche Stoßzeiten mit <br />Verdreifachung<br />der Anfragen<br />stern.tv<br />Verzehnfachung d...
Ziele des Vortrags<br />Wir kochen auch nur mit Wasser.<br />Performanz ist wichtig. Einfach ist wichtiger.<br />„Gut-genu...
Infrastruktur<br />Storage<br />NFSv4<br />.php, .jpg, .css…<br />Webserver<br />CentOS 6.0<br />(Apache, <br />PHP 5.3 + ...
Deployment<br />Betrieb (Systemadmins)<br />Entwicklung<br />Stage<br />Live<br />Integration<br />Webistrano<br />Dev-(Im...
„One-Click-Install“<br />Alle Live-Konfigurationen im SVN<br />Alle Instanzen (Dev, Integration, Stage und Live) funktioni...
MySQL (ebenfalls auf localhost umgebogen)</li></ul>Redaktionelle Hochlastseiten<br />10<br />Applikation ist sofort nach S...
Der „Geld spielt keine Rolle“-Ansatz<br />Request: bis 500 MB<br />Server: 16 GB Ram<br />Maximal 32 gleichzeitige Request...
Klassifizierung der Requests<br />Dynamische Requests<br />Ein dynamischer Request (HTML)über PHP<br />zusammengefügt.<br ...
Trennung der Inhalte<br />3 Sub-Domains für verschiede statische Inhalte<br />s1.stern.de => Bilder, CSS, JS zur Applikati...
Trennung der Inhalte<br />160.000.000 Requests<br />Dynamische Inhalte<br />maximal 32 gleichzeitige Anfragen<br />15.840....
HTTP-Cache-Control-HeaderBrowser-Cache<br />Redaktionelle Hochlastseiten<br />15<br />Anweisungen für Caches<br />Wie lang...
HTTP-Cache-Control-Header<br />Browser-Cache<br />Redaktionelle Hochlastseiten<br />16<br />160.000.000 Requests<br />Dyna...
HTTP-Accelerator(Web-Cache, Gateway-Cache, Reverse Proxy)<br />„<br />Varnish Cache is an open source, state of the art we...
HTTP-Accelerator(Funktionsweise)<br />Beruht auf HTTP; Verben (Methoden) müssenkorrektgenutztwerden.<br />Redaktionelle Ho...
HTTP-Accelerator<br /><ul><li> 99.9 % Cache-Hitrate bei statischen Inhalten
 70% Cache-Hitrate bei dynamischen Inhalten
stale-if-error
stale-while-revalidate</li></ul>Redaktionelle Hochlastseiten<br />19<br />
HTTP-Accelerator vs. Personalisierung<br />Lösungen<br /><ul><li> Stern-Ansatz: Mach‘s nicht
 FTD-Ansatz: Nutze Ajax
Externer Service (z.B.: Disqus)
Iframes
ESI</li></ul>Redaktionelle Hochlastseiten<br />20<br />
HTTP-Accelerator<br />70%<br />160.000.000 Requests<br />Dynamische Inhalte<br />maximal 32 gleichzeitige Anfragen<br />11...
Byte-Code-Cache<br />Erfahrungsbericht<br />PHP-Code<br />Byte-Code<br />Lexing<br />Parsing<br />$output = „Hello World!“...
 Fehler im APC bringen Konzepte durcheinander
CentOS nicht „patchbar“
 Apache nutzt keine „realen“ Pfade
 stat0 nicht nutzbar</li></ul>PHP-Code<br />Byte-Code<br />$output = „Hello World!“;<br />echo $output;<br />return;<br />...
Byte-Code-Cache<br />Redaktionelle Hochlastseiten<br />23<br />APC<br />70%<br />160.000.000 Requests<br />Dynamische Inha...
Applikation<br />Bis hier noch keine Zeile Applikationscode <br />angefasst, trotzdem Faktor 1000 günstiger!<br /> für 70%...
„<br />Free & open source, high-performance, distributed memory object caching system, generic in nature, but intended for...
Memcached als Objectcache<br />memcache-<br />Server<br />Webserver<br />stern.de<br /><ul><li>Keys werden geprefixed
Upcoming SlideShare
Loading in...5
×

Redaktionelle Hochlastwebseiten am Beispiel von stern.de

24,917

Published on

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.

Published in: Technology

Transcript of "Redaktionelle Hochlastwebseiten am Beispiel von stern.de"

  1. 1. Redaktionelle Hochlastseiten<br />Nils Langner, Gruner + Jahr<br />Mike Lohmann, Gruner + Jahr ICANS GmbH<br />
  2. 2. Wir.<br />Mike Lohmann<br />Architektur<br />Autor (PHPMagazin)<br />Stolzer Papa<br />Nils Langner<br />Qualitätsmanagement und Architektur<br />Blogger (www.phphatesme.com)<br />Stolzer Papa<br />Redaktionelle Hochlastseiten<br />2<br />
  3. 3. Agenda.<br />Redaktionelle Hochlastseiten<br />3<br /><ul><li>Redaktionelle Webseiten.
  4. 4. Infrastruktur und Deployment.
  5. 5. Günstiger und schneller ausliefern ohne Codeanpassung.
  6. 6. Nutzung von CDN und ESI.</li></li></ul><li>Gruner + Jahr<br />Redaktionelle Hochlastseiten<br />4<br />
  7. 7. Redaktionelle Webseiten<br />„Keine“ vom User<br />erstellten Inhalte<br />„kleine“ Gruppe <br />von Redakteuren<br />Überschaubare Anzahl<br />neuer Artikel<br />Seiten bestehen aus<br /> vielen statischen Einzelkomponenten<br />Redaktionelle Hochlastseiten<br />5<br />
  8. 8. stern.de in Zahlen<br />Tägliche Stoßzeiten mit <br />Verdreifachung<br />der Anfragen<br />stern.tv<br />Verzehnfachung der Anfragen<br />Größe der Startseite <br />über1MB<br />160.000.000 <br />Seitenabrufe<br />„Kernarbeitszeiten“<br />7-21 Uhr<br />16.000.000.000<br />Requests<br />Sieben Seitenabrufe <br />pro Besuch<br />Redaktionelle Hochlastseiten<br />6<br />
  9. 9. Ziele des Vortrags<br />Wir kochen auch nur mit Wasser.<br />Performanz ist wichtig. Einfach ist wichtiger.<br />„Gut-genug“-Prinzip: Lösung folgt Anforderung.<br />Praxiserfahrungen vermitteln.<br />Funky Technologien.<br />Frontend-Performance.<br />Redaktionelle Hochlastseiten<br />7<br />
  10. 10. Infrastruktur<br />Storage<br />NFSv4<br />.php, .jpg, .css…<br />Webserver<br />CentOS 6.0<br />(Apache, <br />PHP 5.3 + Module)<br />Datenbank<br />MySQL 5.1<br />Redaktionelle Hochlastseiten<br />8<br />
  11. 11. Deployment<br />Betrieb (Systemadmins)<br />Entwicklung<br />Stage<br />Live<br />Integration<br />Webistrano<br />Dev-(Image)<br />SVN<br />Redaktionelle Hochlastseiten<br />9<br />
  12. 12. „One-Click-Install“<br />Alle Live-Konfigurationen im SVN<br />Alle Instanzen (Dev, Integration, Stage und Live) funktionieren mit Live-Konfiguration<br /><ul><li>Memcached (Adressen in Dev und Integration auf localhost umgebogen)
  13. 13. MySQL (ebenfalls auf localhost umgebogen)</li></ul>Redaktionelle Hochlastseiten<br />10<br />Applikation ist sofort nach SVN EXPORT lauffähig<br />Voraussetzung für Release über Webistrano, da keine Scripte ausgeführt werden können.<br />
  14. 14. Der „Geld spielt keine Rolle“-Ansatz<br />Request: bis 500 MB<br />Server: 16 GB Ram<br />Maximal 32 gleichzeitige Request<br />16.000.000.000 Requests<br />16.000.000.000<br />1.512.000<br />10582<br />31746<br />Requests<br />Sekunden<br />Requests pro Sekunde<br />Requests in Spitzenzeiten<br />5958 Server<br />Die Site benötigt 6 Sekunden zum Berechnen!<br />Redaktionelle Hochlastseiten<br />11<br />
  15. 15. Klassifizierung der Requests<br />Dynamische Requests<br />Ein dynamischer Request (HTML)über PHP<br />zusammengefügt.<br />Statische Requests<br />100 statische Requests auf css-, js- und<br />Bilddateien.<br />Redaktionelle Hochlastseiten<br />12<br />
  16. 16. Trennung der Inhalte<br />3 Sub-Domains für verschiede statische Inhalte<br />s1.stern.de => Bilder, CSS, JS zur Applikation gehörig<br />d1.stern.de => Bilder, von Usern erstellt<br />c1.stern.de => Bilder, CSS, JS, zu einem Inhalt gehörig und über das CMS erstellt<br />Config-Datei zur Konfiguration der Sub-Domain für die verschiedenen Inhalte<br />1 Domain für dynamische Inhalte (von PHP prozessiert)<br />stern.de => HTML, XML, RSS, JSON<br />Redaktionelle Hochlastseiten<br />13<br />
  17. 17. Trennung der Inhalte<br />160.000.000 Requests<br />Dynamische Inhalte<br />maximal 32 gleichzeitige Anfragen<br />15.840.000.000 Requests<br />Statische Inhalte<br />6000 Anfragen pro Sekunde<br />106<br />318<br />10476<br />31429<br />dynamische Requests im Schnitt<br />dynamische Requests im Peak<br />statische Requests pro Sekunde<br />Statische Requests im Peak<br />60<br />6<br />66 Server<br />Redaktionelle Hochlastseiten<br />14<br />
  18. 18. HTTP-Cache-Control-HeaderBrowser-Cache<br />Redaktionelle Hochlastseiten<br />15<br />Anweisungen für Caches<br />Wie lange ist ein bestimmter Inhalt gültig?<br />2 Caching-Strategien<br />Auslaufen -> Expires<br />Verifizieren -> If-Modified-Since, ETag<br />s1.stern.de = Expires („unendlich“, Invalidierung über ?id=<hash>)<br />c1.stern.de und d1.stern.de = Expires (begrenzt) + Validation<br />stern.de = Expires (abhängig vom Alter des Artikels)<br />Beispiel<br />
  19. 19. HTTP-Cache-Control-Header<br />Browser-Cache<br />Redaktionelle Hochlastseiten<br />16<br />160.000.000 Requests<br />Dynamische Inhalte<br />maximal 32 gleichzeitige Anfragen<br />11.088.000.000 Requests<br />Statische Inhalte<br />6000 Anfragen pro Sekunde<br />dynamische Requests im Schnitt<br />dynamische Requests im Peak<br />statische Requests pro Sekunde<br />Statische Requests im Peak<br />60<br />106<br />318<br />7334<br />22000<br />4<br />64 Server<br />
  20. 20. HTTP-Accelerator(Web-Cache, Gateway-Cache, Reverse Proxy)<br />„<br />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.<br />“<br />Redaktionelle Hochlastseiten<br />17<br />
  21. 21. HTTP-Accelerator(Funktionsweise)<br />Beruht auf HTTP; Verben (Methoden) müssenkorrektgenutztwerden.<br />Redaktionelle Hochlastseiten<br />18<br />
  22. 22. HTTP-Accelerator<br /><ul><li> 99.9 % Cache-Hitrate bei statischen Inhalten
  23. 23. 70% Cache-Hitrate bei dynamischen Inhalten
  24. 24. stale-if-error
  25. 25. stale-while-revalidate</li></ul>Redaktionelle Hochlastseiten<br />19<br />
  26. 26. HTTP-Accelerator vs. Personalisierung<br />Lösungen<br /><ul><li> Stern-Ansatz: Mach‘s nicht
  27. 27. FTD-Ansatz: Nutze Ajax
  28. 28. Externer Service (z.B.: Disqus)
  29. 29. Iframes
  30. 30. ESI</li></ul>Redaktionelle Hochlastseiten<br />20<br />
  31. 31. HTTP-Accelerator<br />70%<br />160.000.000 Requests<br />Dynamische Inhalte<br />maximal 32 gleichzeitige Anfragen<br />11.088.000.000 Requests<br />Statische Inhalte<br />6000 Anfragen pro Sekunde<br />99.9 %<br />Redaktionelle Hochlastseiten<br />21<br />dynamische Requests im Schnitt<br />dynamische Requests im Peak<br />statische Requests pro Sekunde<br />Statische Requests im Peak<br />32<br />96<br />7<br />22<br />18<br />1<br />19 Server<br />
  32. 32. Byte-Code-Cache<br />Erfahrungsbericht<br />PHP-Code<br />Byte-Code<br />Lexing<br />Parsing<br />$output = „Hello World!“;<br />echo $output;<br />return;<br />ASSIGN !0 ‚Hello+World%21‘<br />ECHO !0<br />RETURN 1<br />ZEND_HANDLE_EXCEPTION<br />Execution<br /><ul><li> dank APC ist es möglich NFS zu nutzen
  33. 33. Fehler im APC bringen Konzepte durcheinander
  34. 34. CentOS nicht „patchbar“
  35. 35. Apache nutzt keine „realen“ Pfade
  36. 36. stat0 nicht nutzbar</li></ul>PHP-Code<br />Byte-Code<br />$output = „Hello World!“;<br />echo $output;<br />return;<br />ASSIGN !0 ‚Hello+World%21‘<br />ECHO !0<br />RETURN 1<br />ZEND_HANDLE_EXCEPTION<br />Execution<br />Redaktionelle Hochlastseiten<br />22<br />
  37. 37. Byte-Code-Cache<br />Redaktionelle Hochlastseiten<br />23<br />APC<br />70%<br />160.000.000 Requests<br />Dynamische Inhalte<br />maximal 32 gleichzeitige Anfragen<br />11.088.000.000 Requests<br />Statische Inhalte<br />6000 Anfragen pro Sekunde<br />99.9 %<br />dynamische Requests im Schnitt<br />dynamische Requests im Peak<br />statische Requests pro Sekunde<br />Statische Requests im Peak<br />32<br />96<br />7<br />22<br />6<br />1<br />7 Server<br />
  38. 38. Applikation<br />Bis hier noch keine Zeile Applikationscode <br />angefasst, trotzdem Faktor 1000 günstiger!<br /> für 70% der User nur noch 150ms für einen<br />Seitenaufruf.<br />Anmerkung für den Redner: Stehende Ovationen abwarten!<br />Redaktionelle Hochlastseiten<br />24<br />
  39. 39. „<br />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.<br />“<br />Redaktionelle Hochlastseiten<br />25<br />
  40. 40. Memcached als Objectcache<br />memcache-<br />Server<br />Webserver<br />stern.de<br /><ul><li>Keys werden geprefixed
  41. 41. stern_v191_key1
  42. 42. Ändern des Präfixes beim Deployment</li></ul>Sharding wird von memcached<br />nativ unterstützt<br />Redaktionelle Hochlastseiten<br />26<br />
  43. 43. Memcached als Objectcache<br />Redaktionelle Hochlastseiten<br />27<br />APC<br />Mem<br />70%<br />Dynamische <br />Inhalte<br />maximal 32 <br />gleichzeitige <br />Anfragen<br />160.000.000 Requests<br />11.088.000.000 Requests<br />Mem<br />Statische <br />Inhalte<br />6000 Anfragen <br />pro Sekunde<br />99.9 %<br />dynamische Requests im Schnitt<br />dynamische Requests im Peak<br />statische Requests pro Sekunde<br />Statische Requests im Peak<br />32<br />96<br />7<br />22<br />3<br />1<br />4 Server<br />
  44. 44. sleep<br />Redaktionelle Hochlastseiten<br />28<br />
  45. 45. Übersicht<br />„Geld spielte keine Rolle“-Ansatz<br />Trennung der Inhalte nach Typ<br />Cache-Header<br />HTTP-Accelerator<br />Byte-Code-Cache<br />Memcache<br />5958 Server<br />66 Server<br />64 Server<br />19 Server<br />7 Server<br />4Server<br />Redaktionelle Hochlastseiten<br />29<br />148.950 %<br />
  46. 46. stern.tv<br />Redaktionelle Hochlastseiten<br />30<br /><ul><li>Verzehnfachung der Last
  47. 47. Kein Problem für dynamische Inhalte!
  48. 48. -> Cache-Hit-Rate erhöht sich drastisch, weil
  49. 49. Last nur für 10 – 20 versch. Seiten
  50. 50. Problem ist die Anbindung (2Gbit + 1Gbit Redundanz)
  51. 51. Lösung: CDN</li></li></ul><li>CDN<br />Redaktionelle Hochlastseiten<br />31<br />Eigenes Rechenzentrum<br />Normal case<br />Eigenes Rechenzentrum<br />sternTVcase<br />CDN<br />
  52. 52. ESI(Edge Side Includes)<br />Gültigkeit: 1 Tag<br /><esi:include<br />src=http://www.stern.de/esi/header<br />onerror="continue"/><br />Gültigkeit: 1 Minute<br />Gültigkeit: 2 Stunden<br />Gültigkeit: 5 Minuten<br />Redaktionelle Hochlastseiten<br />32<br />
  53. 53. ESI<br />worstcase<br />averagecase<br />Redaktionelle Hochlastseiten<br />33<br />
  54. 54. ESI bei neon.de<br />Cachezeiten<br />Renderzeiten<br />300 Sek.<br />0 Sek.<br />300 Sek. <br />0 Sek.<br />1 Sek.<br />1 Sek.<br />1 Sek.<br />1 Sek.<br />2 Sek.<br />Redaktionelle Hochlastseiten<br />34<br />
  55. 55. Framework<br />SternFramework<br /><ul><li> das beste Framework (damals)
  56. 56. wir können alles anpassen
  57. 57. wir können alles anpassen
  58. 58. ESI-Implementierung kostspielig
  59. 59. keine externen Entwickler „zukaufbar“
  60. 60. Großer Footprint
  61. 61. das beste Framework (heute)
  62. 62. ESI-Unterstützung
  63. 63. Standard
  64. 64. Skaliert über Entwickler
  65. 65. Kleiner Footprint
  66. 66. Rewrite</li></ul>Redaktionelle Hochlastseiten<br />35<br />
  67. 67. Danke.<br />?<br />Fragen<br />Redaktionelle Hochlastseiten<br />36<br />
  68. 68. Kontaktdaten<br />Nils Langner<br />nils.langner@phmlabs.com<br />phphatesme<br />Mike Lohmann<br />mike.lohmann@phmlabs.com<br />mikelohmann<br />Redaktionelle Hochlastseiten<br />37<br />
  69. 69. Links<br />Redaktionelle Hochlastseiten<br />38<br />Gruner + Jahr: http://www.guj.de/<br />ESI (Varnish): https://www.varnish-cache.org/trac/wiki/ESIfeatures<br />Memcached:http://memcached.org/<br />Varnish: https://www.varnish-cache.org/<br />Symfony2: http://www.symfony.com<br />HTTP-Header: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html<br />ESI-W3: http://www.w3.org/TR/esi-lang<br />
  70. 70. Tools<br />Redaktionelle Hochlastseiten<br />39<br /><ul><li>Bamboo
  71. 71. Jira
  72. 72. Confluence
  73. 73. Cruicible
  74. 74. Fisheye
  75. 75. Greenhopper
  76. 76. phpUnit
  77. 77. pDepend
  78. 78. jMeter
  79. 79. Zend Studio
  80. 80. xDebug
  81. 81. Zend Framework
  82. 82. Symfony2
  83. 83. phpcpd
  84. 84. LiveTest
  85. 85. Webistrano/Capistrano
  86. 86. PHP_CodeSniffer
  87. 87. PTI
  88. 88. SVN
  89. 89. Git
  90. 90. MySQL
  91. 91. Teamsite
  92. 92. FirstSpirit
  93. 93. jQuery
  94. 94. Memcached
  95. 95. Ant
  96. 96. jsUnit
  97. 97. Vmware
  98. 98. Oracle
  99. 99. Windows7
  100. 100. CentOS</li></li></ul><li>„Release über Webistrano“<br />Applikation liegt auf Stage und Live in Verzeichnis mit Versionsnummer<br /> -> Link auf das Live-Release-Verzeichnis<br />Memcached<br /> -> Values mit Key+Version gespeichert<br />Config-Cache (Symfony)<br /> -> Realpath auf Dateien<br />Neues Release = neues Verzeichnis<br /> -> altes Release immer noch vorhanden (auch Caches) <br />Livegang ist atomar (Linkwechsel)<br /> -> Rollback sehr schnell möglich<br />! Noch keine Lösung für Strukturänderungen an Datenbanken! <br />=> Noch nie vorgekommen<br />Redaktionelle Hochlastseiten<br />40<br />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×