Kategorien
An die Konferenzfront
Wer von euch hat gedacht, dass es heute keinen Beitrag mehr gibt? Jeder? Ätsch, voll vera*****! Naja eigentlich wollte ich schon heute Morgen was livestellen, aber da ich am Samstag kirchlich heirate ist mein Terminplan derzeit ein wenig hektische und dann muss man halt mal Abends bloggen. Und vielleicht muss man auch mal den ein oder anderen kürzeren Artikel schreiben.
Genug Einleitung, jetzt zum Thema. Ich wollte dieses Jahr meine Präsenz im Konferenzkosmos ein wenig steigern, nicht nur als Besucher, sondern auch als Speaker. Irgendwie habe ich Lust mein Wissen auch mal so zu verteilen. Wie man das so macht stellt man sich also ein oder mehrere Präsentationen zusammen und reicht die bei allen möglichen Events ein. Bei mir sind es DeveloperConfernce, Froscon, IPC und Unconference und Vorträge will ich zwei vorbereiten.
Redaktionelle Hochlastseiten am Beispiel von stern.de
Wie schafft man es 170.000.000 Seitenabrufe im Monat mit nur fünf Webservern zu bewerkstelligen. Wie verhält sich eine Webseite wenn im Fernsehen darüber berichtet wird. Das Ganze soll ein Talk über Infrastruktur, Architektur und Herausforderungen werden. Buzzwords hier wären ESI, Gateway-Cache, Memcache, CDN, statische vs. dynamische Inhalte.
Buzzword-Bingo
Das war eine Idee, die ich vor kurzem hatte. Warum nicht mal einen Vortrag einreichen, bei dem man alle aktuellen Technologien und spannende Themen in jeweils 5min vorstellt. Drumrum packt man noch ein kleines Bingo-Spiel. Ich glaub das würde gut auf eine Konferenz wie die IPC passen, ganz am Anfang und nach jedem Punkt erwähnt man noch die Session auf dem Event, in der man mehr zu diesem Thema erfährt. Sollte dann nach natürlich nicht die letzte Session am letzten Tag sein.
So jetzt dürft ihr euren Senf dazugeben und vielleicht noch ein paar Tipps geben, was man noch alles erzählen könnte.
Die Vorträge hören sich auf jeden Fall interessant an.
Habe bisher nur kleine und paar mittelgroße Webanwendungen aufgesetzt und es würde mich echt mal interessieren, wie man große Webanwendungen stemmt und was man dort anders macht bzw. worauf man achten muss. Habe vor zwei Jahren bei der Zend Roadshow einen kleinen Einblick bekommen, aber dein Vortrag scheint da ausführlicher zu sein.
Bei einigen der genannten Konferenzen werde ich auch anwesend sein und bin gespannt dich auch mal im Reallife kennenzulernen 🙂 Auf der PHP Unconference letztes Jahr hat es ja leider nicht geklappt, aber da hattest du ja eine gültige Ausrede 😉
Die Idee mit dem Buzzword Bingo klingt großartig und würde sich auch perfekt dazu eignen den Talk zu zweit zu machen – haste Lust? 😀
Glückwunsch zur Hochzeit, aber wäre es denkbar deinen deinen Kram einfach mal aussen vor zu lassen?
Ach Nils … ich glaube, wir müssen uns mal unterhalten!
@Nils: Glückwunsch auch von mir.
@KingCrunch: Lass ihn doch, schließlich geht es im Leben nicht nur um Bits und Bytes und ein wenig was persönliches ist doch ok. Wenn es dich stört, überlies doch einfach immer den ersten Absatz. 😉
Beispiel Stern.de: An denen sieht man das dieses ganze Caching auch seine Nachteile hat.
Wenn diese einen Tweet absetzen zu einem Neuen Artikel landet man(ich) zu 99% auf der nicht gefunden Seite wenn man innerhalb der ersten Minute draufklickt.
@Sonyon: Das werde ich mal checken. Hat eigentlich nichts mit Caching zu tun, klingt eher nach einem Bug. Ich halte dich auf dem Laufenden.
Erstmal Glücksstrumpf zum Weib! Mögen noch viele weitere … ach nee, eine reicht. 😀
170 Mio. Seitenaufrufe sind zur Spitzenlast maximal 300 gleichzeitige Aufrufe. Wenn die mal Ihre Seite aufräumen würden, kämen Sie auch mit 3 modernen Servern aus.
Also in Kürze aus meiner Erfahrung mit HQ Traffic:
Im Hintergrund
– niemals Apache (lieber Cherokee => mein Favorit, nginx oder im Zweifel auch lighty)
– wichtig ist viel viel Ram in der DB und großzügiges Caching! (und noch ein viel dabei)
– Tabellen, die sich nicht ändern, als memtable laufen lassen
– Logs aus oder aus dem Ram sichern (ein paar Webserver können das)
– wenn sich die Seiten nicht dauernd ändern, kann sich auch ein reverse squid lohnen
– abgestuftes Caching (kurze Zeiten, lange Zeiten)
– Memcache lohnt nur für Riesenprojekte mit vielen verteilten Daten (siehe youtube) – ansonsten lieber APC oder XCache, weil wesentlich (!!!) schneller
– gzip an und am besten auch als gzip cachen
Im html:
– sauberes und schnelles html (also das Gegenteil von dem, was Stern da macht)
– Requests generell vermeiden mit langen expires, etags und not modified headern
– möglichst wenig Requests und wenig Elemente (also das Gegenteil vom Stern)
– wenig Werbung, weil zu viele ungecachte Daten (und wieder, das Gegenteil …)
– ein CDN ist meistens unnötig, kann man machen, bringt aber für redaktionelle Seiten wenig, lieber lange Cachingzeiten und eine (nicht drei!) Domain für alles Statische
– Javascript defer oder async laden
Das sind so die wichtigsten Regeln, um es richtig schnell zu bekommen.
Der erste Beitrag wurde bei der froscon angenommen. Freue mich, ihn jetzt endlich vorbereiten zu dürfen.