• Redaktionelle Hochlastwebseiten am Beispiel von stern.de

    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.

    Der Vortrag Redaktionelle Hochlastwebseiten am Beispiel von stern.de wurde in den Kategorien Allgemein, PHP, Vorträge einsortiert.

    Diese Präsentation auf Slideshare

    14 Kommentare »


    • loci
      am 14. Oktober 2011 um 15:21 Uhr

      Schade finde ich ein wenig, dass die Anzahl der Requests durch die statischen Aufrufe auf Bilder/CSS/JS etc. ein wenig geschoent sind. Hier kann schon ein einfacher nginx mind. 5k Req/s handeln.
      Ansonsten war der Talk nett gemacht und immer mal wieder ein wenig zum Schmunzeln. sleep(x) z.B.

      BTW: Wie kommt ihr auf Folie 11 an 1.512.000 Sekunden?


    • Oliver
      am 14. Oktober 2011 um 15:38 Uhr

      Naja, die 16.000.000.000 Requests wundern kaum, wenn man sich den Quelltext anschaut. „The page has a total of 171 components and a total weight of 1581.8K bytes“ – ja, nee – ist klar. Lad das mal über ISDN. :-)


    • Tobias
      am 14. Oktober 2011 um 16:16 Uhr

      Die stern.de Seite musst bei meiner Diplomarbeit auch immer als Test-Seite herhalten.
      Da konnte man schön aufzeigen wie ältere Rechner und ältere Web-Browser leiden müssen ;-)


    • Nils Langner
      am 14. Oktober 2011 um 17:11 Uhr

      Aber wer hat schon ISDN.


    • Nils Langner
      am 14. Oktober 2011 um 17:14 Uhr

      @loci: Ein Apache kann ja auch 6.000 Requests pro Sekunde, aber wir hatten ja im Talk gesagt, dass wir die Trennung sogar wieder aufgehoben haben, weil sie dank der anderen Optimierungen nicht mehr nötig ist.

      Die Sekunden kommen von 14 Stunden am Tag Last und die andere Zeit nichts.

      @Tobias: Magst du uns vielleicht mal die Diplomarbeit zukommen lassen? Dann schicke ich die mal bei den Kollegen rum, ist sicherlich interessant.


    • Jan
      am 15. Oktober 2011 um 12:31 Uhr

      Wenn ich mir die Slides so anschaue, seid ihr wohl auf ähnliche Lösungen gekommen wie wir (Varnish, Memcache). Nutzt ihr überall statische Cache-Zeiten oder arbeitet ihr auch mit purges?


    • Matthias Zeis
      am 15. Oktober 2011 um 20:20 Uhr

      Hallo Nils,

      dankeschön für die Slides, finde ich sehr interessant! Eine Frage zum Reverse-Proxy/HTTP-Accelerator: habt ihr eine einzige Kiste mit Varnish herumstehen, welche die 318 dynamischen plus 22.000 statischen Requests im Peak bewältigen kann? Oder je 1 für dynamisch/statisch? Oder läuft Varnish auf jedem Server? So viele “oder”…

      Danke und beste Grüße,
      Matthias


    • Nils Langner
      am 15. Oktober 2011 um 22:34 Uhr

      @Jan : Nein wir invalidieren nicht aktiv, dass passiert nur über Auslaufen des Gültigkeitszeitraums. Für wen arbeitest du denn?

      @Matthias: Wir haben 17 Varnishes im Einsatz, die sind aber für ca. 40 Webseites im Einsatz.


    • Jan
      am 18. Oktober 2011 um 18:15 Uhr

      @Nils: Sorry, hatte den Post komplett verdrängt. Ich arbeite für die Newsfactory, wir haben da einige recht große Portalkunden mit unserem System. Du hattest glaub ich auch schonmal Kontakt mit meinem Ex-Kollegen Stephan zwecks eines Javascript-Artikels damals :)


    • Malte Blättermann
      am 18. Oktober 2011 um 19:31 Uhr

      Hallo,

      super Präsentation, die einen guten Überblick gibt, was man wirklich konkret einsparen kann, wenn man sich bei der Konzeption eines Projekts bereits mit Hochlast-Problemen beschäftigt.

      Im ersten Moment sicher mehr Aufwand, aber letzten Endes günstiger als die komplette Applikation umzubauen, sobald ein wenig Traffic auf die Site kommt.

      Also: Den potenziellen Erfolg ein Web-App sollte man einplanen.

      Danke fürs Teilen!! :)


    • christian
      am 27. Oktober 2011 um 13:48 Uhr

      Hallo Niels,

      tolle Infos über den Stern. Ich frag mich allerdings ab und an, warum die Startseite kaum auf semantisches HTML achtet. Statt H1, H2 etc., werden den Überschriften nur DIVs bzw. den A Tags nur H2 CSS Klassen (oder .headline Klassen) zugeordnet.

      Der Stern ist da nicht der einzige, auch andere große Nachrichtenseiten überraschen bei Neugestalltung mit so einer class und div Suppe.

      Meine Frage daher, ist das Absicht oder eher fehlendes Wissen bei den Frontendentwicklern? Hat das CMS Probleme bei der Umsetzung von semantischen Quellcode oder wird das einfach nicht als wichtig erachtet?

      Viele Grüße

      Christian


    • Nils Langner
      am 27. Oktober 2011 um 14:27 Uhr

      @Christian: Da bist du nicht der einzige, der sich das fragt. Bei der Frontendgeschichte bin ich aber auch vollständig raus. Ich gehe aber davon aus, dass irgendein SEO mal gesagt hat, es muss so gemacht werden und dann wurde es so gemacht.


    • Tobias
      am 30. Oktober 2011 um 14:53 Uhr

      Hallo Nils,

      ich hab meine Diplomarbeit auf Slideshare und meinem Blog online gestellt:
      http://scheible.eu/diplomarbeit_tobias_scheible/

      Ist schon etwas älter (2009). Das Thema war: “Erhebung von Anforderungen an asynchrone Web-Anwendungen”.

      Grüße
      Tobias


    • Nächste Vortragsrunde | PHP hates me - Der PHP Blog
      am 18. November 2011 um 07:03 Uhr

      [...] fürs nächste Jahr wieder etwas ähnliches vorgenommen. Unsere Tour 2011 hatte ja den Titel “Redaktionelle Hochlastwebseiten am Beispiel von stern.de” und ich glaube sie kam überall gut an, zumindest sagen die Feedbackbögen dies. Bei der [...]

    RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

    Hinterlasse einen Kommentar

    Wir wurden schon öfters gefragt, ob man uns nicht irgendwie unterstützen kann. Die Antwort war immer einfach: Klar! Am einfachsten ist es eure nächsten Einkäufe bei Amazon über unsere Link abzuwickeln. Damit würdet ihr uns schon sehr helfen. Über Co-Autoren freuen wir uns aber noch mehr.