Facebook
Twitter
Google+
Kommentare
14
Willkommen bei "the web hates me". Mittlerweile hat unser Team ein tolles neues Monitoringtool für Agenturen gelauncht. Unter dem Namen koality.io haben wir einen Service geschaffen, der er Agenturen ermöglicht mit sehr geringen Kosten alle Ihre Webseiten zu überwachen.

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.

Über den Autor

Nils Langner

Nils Langner ist der Gründer von "the web hates me" und auch der Hauptautor. Im wahren Leben leitet er das Qualitätsmanagementteam im Gruner+Jahr-Digitalbereich und ist somit für Seiten wie stern.de, eltern.de und gala.de aus Qualitätssicht verantwortlich. Nils schreibt seit den Anfängen von phphatesme, welches er ebenfalls gegründet hat, nicht nur für diverse Blogs, sondern auch für Fachmagazine, wie das PHP Magazin, die t3n, die c't oder die iX. Nebenbei ist er noch ein gern gesehener Sprecher auf Konferenzen. Herr Langner schreibt die Texte über sich gerne in der dritten Form.
Kommentare

14 Comments

  1. 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?

    Reply
  2. 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. 🙂

    Reply
  3. 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 😉

    Reply
  4. @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.

    Reply
  5. 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?

    Reply
  6. 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

    Reply
  7. @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.

    Reply
  8. @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 🙂

    Reply
  9. 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!! 🙂

    Reply
  10. 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

    Reply
  11. @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.

    Reply

Leave a Comment.

Link erfolgreich vorgeschlagen.

Vielen Dank, dass du einen Link vorgeschlagen hast. Wir werden ihn sobald wie möglich prüfen. Schließen