Redaktionelle Hochlastwebseiten am Beispiel von stern.de

  • 24,409 views
Uploaded 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 …

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
24,409
On Slideshare
0
From Embeds
0
Number of Embeds
10

Actions

Shares
Downloads
87
Comments
0
Likes
14

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
  • 3. Agenda.
    Redaktionelle Hochlastseiten
    3
    • Redaktionelle Webseiten.
    • 4. Infrastruktur und Deployment.
    • 5. Günstiger und schneller ausliefern ohne Codeanpassung.
    • 6. Nutzung von CDN und ESI.
  • Gruner + Jahr
    Redaktionelle Hochlastseiten
    4
  • 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
  • 12. „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)
    • 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
  • 22. HTTP-Accelerator
    • 99.9 % Cache-Hitrate bei statischen Inhalten
    • 23. 70% Cache-Hitrate bei dynamischen Inhalten
    • 24. stale-if-error
    • 25. stale-while-revalidate
    Redaktionelle Hochlastseiten
    19
  • 26. HTTP-Accelerator vs. Personalisierung
    Lösungen
    • Stern-Ansatz: Mach‘s nicht
    • 27. FTD-Ansatz: Nutze Ajax
    • 28. Externer Service (z.B.: Disqus)
    • 29. Iframes
    • 30. ESI
    Redaktionelle 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
  • 32. Byte-Code-Cache
    Erfahrungsbericht
    PHP-Code
    Byte-Code
    Lexing
    Parsing
    $output = „Hello World!“;
    echo $output;
    return;
    ASSIGN !0 ‚Hello+World%21‘
    ECHO !0
    RETURN 1
    ZEND_HANDLE_EXCEPTION
    Execution
    • dank APC ist es möglich NFS zu nutzen
    • 33. Fehler im APC bringen Konzepte durcheinander
    • 34. CentOS nicht „patchbar“
    • 35. Apache nutzt keine „realen“ Pfade
    • 36. stat0 nicht nutzbar
    PHP-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
  • 40. Memcached als Objectcache
    memcache-
    Server
    Webserver
    stern.de
    • Keys werden geprefixed
    • 41. stern_v191_key1
    • 42. Ändern des Präfixes beim Deployment
    Sharding 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 %
  • 46. stern.tv
    Redaktionelle Hochlastseiten
    30
    • Verzehnfachung der Last
    • 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)
    • 51. Lösung: CDN
  • CDN
    Redaktionelle Hochlastseiten
    31
    Eigenes Rechenzentrum
    Normal case
    Eigenes Rechenzentrum
    sternTVcase
    CDN
  • 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
  • 55. Framework
    SternFramework
    • das beste Framework (damals)
    • 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. Rewrite
    Redaktionelle 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
  • 70. Tools
    Redaktionelle Hochlastseiten
    39
  • „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
    Redaktionelle Hochlastseiten
    40