„Warum ist deine Website abgestürzt? Du musst doch gewusst haben, dass viel los sein würde!“
Das hört man oft, wenn eine Website in einem entscheidenden Moment zusammenbricht. In den sozialen Medien werden immer wieder dieselben Fragen gestellt, im gleichen vorwurfsvollen Ton. „Die müssen doch gewusst haben, dass viel los sein würde. Warum haben sie nicht einfach ein paar zusätzliche Giga-irgendwas reingesteckt?“
Für die enttäuschten Nutzer scheint es offensichtlich, dass ein Unternehmen vor einem starken Anstieg des Datenverkehrs mehr vorbeugende Maßnahmen hätte ergreifen müssen und dass das Einzige, was möglicherweise schiefgelaufen sein könnte, eine schlechte Planung war.
Aber wie sehen diese vorbeugenden Maßnahmen aus? Lasttests? Ein „größerer Server“? Vielleicht mehr Server? Oder wie wäre es mit einer dieser magischen, skalierbaren serverlosen Clouds…?!
- Lesen Sie: Warum der Umstieg auf „einen größeren Server“ Ihre Website nicht vor Traffic-Spitzen bewahren wird
Oftmals treffen wir die Webentwickler eines Teams zum ersten Mal bei einer CrowdHandler-Einführungsveranstaltung an, wo sie mit eingezogenem Schwanz dastehen. Sie haben das Gefühl, versagt zu haben. Sie haben alles vorschriftsmäßig gemacht, und trotzdem blieb die Website nicht online – und nun müssen sie sie aus Zeitgründen notdürftig mit einem Wartezimmer zusammenflicken. Die ersten zehn Minuten des Treffens werden damit verbracht, die Ausreden aus dem Weg zu räumen.
Das haben wir schon oft gehört. Ihr baut die Plattform gerade neu auf, und die neue Website wird diese Probleme nicht haben. Ihr habt eine veraltete Codebasis geerbt, die ihr nicht ändern könnt. Ihr sitzt fest mit einer alten Version von Framework X, das für seine Leistungsprobleme berüchtigt ist. Ihr könntet natürlich alle Probleme beheben; es ist nur eine Frage des Zeitpunkts.
Der Grund für diese heikle Situation liegt darin, dass die meisten Engpässe – also die Probleme, die Websites daran hindern, Tausende und Abertausende von Nutzern zu bewältigen – im Code liegen, für den sich die Entwickler verantwortlich fühlen.
Diese Engpässe liegen oft im Backend: hinter der Benutzeroberfläche – beispielsweise in einem System für den Ticketverkauf, die Terminvergabe oder die Kreditkartenabwicklung. Genauso häufig liegen die Engpässe jedoch in der Benutzeroberfläche selbst. Im Webcode. Code, über den die Entwickler die volle Kontrolle haben.
Wenn wir uns die Ausreden der Entwickler anhören, fühlen wir uns dadurch weder selbstgefällig noch überlegen. Was wir vor allem empfinden, ist Anerkennung. Die Wahrheit ist: Niemandes Code ist von Anfang an skalierbar, und das meiste, was man euch über das Schreiben skalierbaren Codes beigebracht hat, ist falsch.
Ich werde dir gleich erklären, warum es nicht deine Schuld ist, aber zuerst möchte ich dir eine neue Sichtweise auf den Warteraum vorstellen.
Die Installation von CrowdHandler bedeutet kein Eingeständnis eines Misserfolgs. Tatsächlich könnte dies der erste Schritt zur Lösung Ihres Skalierbarkeitsproblems sein. Betrachten Sie CrowdHandler nicht als Notlösung, sondern als Diagnosewerkzeug, das Sie bei Ihrer Arbeit unterstützt und Ihnen hilft, sich zu verbessern.
Es ist nicht deine Schuld
Warum liegt es dann nicht an den Entwicklern, wenn die Website den Datenverkehr nicht bewältigen kann?
Der Grund dafür, dass Mainstream-Code voller programmtechnischer Engpässe ist, liegt darin, dass Mainstream-Webentwickler in der Regel nicht an besonders beliebten Websites arbeiten. Wenn Webentwickler sich weiterbilden und Neues lernen, ist ihr Verständnis von Optimierung und dem Schreiben von leistungsfähigem Code – in der Regel – rein theoretischer Natur.
Zu lernen, wie man theoretisch skalierbaren Code schreibt, und dann in der Praxis zu erleben, wie hunderttausend Nutzer auf deine Website strömen, erinnert mich an dieses Zitat von Mike Tyson: „Jeder hat einen Plan, bis er einen Schlag ins Gesicht bekommt.“ Jetzt hast du einen Schlag ins Gesicht bekommen. Darauf kannst du stolz sein! Die überwiegende Mehrheit der Webentwickler arbeitet nie an etwas, das populär genug ist, um herauszufinden, wie sich das anfühlt.
Deshalb möchte ich Ihnen – und Ihrem Chef – sagen: Es ist völlig normal, dass sich Ihre Website nicht wie von Zauberhand an jedes Traffic-Aufkommen anpassen kann. Das sollten Sie auch nicht erwarten.
Wie lautet also die Antwort?
Natürlich möchten Sie Ihre Website so effizient und skalierbar wie möglich gestalten. Allerdings funktionieren viele der vermeintlichen Lösungen für Skalierbarkeit bei den Zahlen, um die es hier geht, in der Praxis nicht.
Man mag sich zwar auf Frameworks und Sprachen konzentrieren, die theoretisch schneller sind, doch im Großen und Ganzen macht das kaum einen Unterschied, wenn man Tausende oder Millionen von Nutzern bedient.
Wissen Sie, was wirklich einen Unterschied macht? Caching. Nicht die Art von präzisem Objekt-Caching, das man mit Memcached in Servernähe betreiben möchte, sondern dieses „Dirty Edge“-HTTP-Caching in der Nähe des Nutzers, das sich so anfühlt, als läge es außerhalb Ihrer Kontrolle. Das verbessert die Leistung tatsächlich, ist aber schwer richtig umzusetzen und lässt sich nur schwer nachträglich in Frameworks und Content-Management-Systeme integrieren, die dies nicht angemessen berücksichtigen.
Man könnte also wohl mit Lasttests beginnen. Aber – auch wenn das vielleicht etwas umstritten ist – ich glaube nicht, dass routinemäßige Lasttests Ihnen viel helfen werden. Meiner Erfahrung nach sind sie oft eine teure Zeitverschwendung.
Warum ist das so? Weil das tatsächliche Nutzerverhalten komplex ist. Sie können für Ihre Lasttests zwar einfache Nutzerabläufe festlegen, bei denen Nutzer eine Seite durchblättern, ein Produkt auswählen, es in den Warenkorb legen und zur Kasse gehen – aber so läuft es in der Realität nicht ab. Dort springen Kunden hin und her, prüfen alle ihre Optionen, ändern ihre Meinung, warten lange, bevor sie Seiten neu laden, und öffnen dann vier Tabs mit verschiedenen Produkten, um diese zu vergleichen. Es könnten Tausende dieser komplizierten Nutzerpfade gleichzeitig ablaufen, die auf unvorhersehbare Weise auf dieselben Datenbankzeilen zugreifen.
Man könnte also eine Reihe von Lasttests in der Staging-Umgebung durchführen, bei denen die Website bei zwei Millionen Nutzern zusammenbricht, und dann zwei Millionen zur „magischen Zahl“ erklären. Doch wie realistisch sind diese zwei Millionen Nutzerabläufe? Spiegeln sie wirklich zwei Millionen authentische, nutzbare Erfahrungen in der Produktionsumgebung wider? Oder wäre die Live-Website schon viel früher abgestürzt, wenn sich die Nutzer realistisch verhalten hätten? (Ganz zu schweigen von dem Moment, in dem jemand beschließt, während des eigentlichen Sonderverkaufs einen umfangreichen Verkaufsbericht zu erstellen … oh, das testen Sie nicht?)
Vergessen wir nicht, dass Lasttests zudem unglaublich zeitaufwendig sind. Selbst mit einem vereinfachten Skript für die Benutzerreise müssen Sie die Tests immer wieder ausführen und dabei Konfigurationsprobleme beheben, bis alles funktioniert. Und wenn es dann funktioniert, müssen Sie die Tests so lange ausführen, bis die Website zusammenbricht. Das kann ein endloser Kreislauf sein. Viele unserer Kunden schaffen es einfach nicht, mit ihren Lasttest-Tools die Traffic-Menge zu erzeugen, die sie in der Praxis erwarten, oder sie empfinden die Kosten dafür als unerschwinglich.
Abschließend noch Folgendes: Die Art von Lasttests, die wir hier beschreiben, ist ein großes Projekt. Ich kenne zahlreiche Unternehmen, die einmal im Jahr einen großen Lasttest durchführen. Dabei bringen sie jedoch mehrmals pro Woche neuen Code in die Produktion. Es ist durchaus möglich, dass eine einzige Codezeile an der falschen Stelle den gesamten Aufwand des Lasttests zunichte macht und die Zahlen, auf die Sie hinarbeiten, komplett verändert. Sie stellen Code mittlerweile mithilfe von Continuous Integration in die Produktion bereit. Wenn es nur eine Möglichkeit gäbe, einen kontinuierlichen Lasttest durchzuführen …
Der Dauerbelastungstest
Ich möchte Sie bitten, CrowdHandler als eine wesentlich produktivere und kostengünstigere Alternative zu herkömmlichen Lasttests in Betracht zu ziehen. Warum? Weil CrowdHandler auf der Grundlage der von ihm geschützten Website praxisnahe, kontinuierliche Leistungsdaten liefert und es Ihnen ermöglicht, effizienter und iterativer zu arbeiten.
Während eines Verkaufs zeigt Ihr Dashboard an, wie lange das Laden der einzelnen Seiten dauert, und fasst die Gesamtleistung der Seiten zusammen. Die Auto-Tune-Funktion von CrowdHandler analysiert in Echtzeit die Seitengeschwindigkeit, erfasst die Anzahl der Nutzer und ermittelt die optimale Rate an neuen Nutzern, die Ihre Website bewältigen kann.
Mit anderen Worten: Es führt einen kontinuierlichen Belastungstest für Ihre Produktionsumgebung durch, wobei echte Nutzer herangezogen werden und die Ergebnisse in Echtzeit angepasst werden.
Aber – anders als bei einem klassischen Lasttest – verfügt er über ein eingebautes Sicherheitsventil: den Warteraum selbst. Sollten die Zahlen weit daneben liegen, ist das Schlimmste, was passieren kann, nicht eine nicht erreichbare Website, sondern eine längere Warteschlange.
Und selbst wenn die Nutzer etwas länger in der Warteschlange stehen, als Ihnen lieb ist, können Sie das Verhalten des Systems in der Praxis beobachten und daraus lernen. Sie können erkennen, welche Seiten besonders langsam sind, und so die Engpässe in Ihrer Anwendung aufspüren, während die automatische Optimierung die Warteschlange verwaltet und für ein positives Nutzererlebnis sorgt. Anhand der Daten aus einem realen Verkaufsstart können Sie erkennen, auf welche Teile der Website Sie sich bei der nächsten Optimierung konzentrieren müssen.
Ohne ein Wartezimmer wäre es sehr unwahrscheinlich, dass Sie einen unbekannten Engpass in Ihrer Anwendung diagnostizieren oder gar erkennen könnten, da Ihre Website nicht mehr funktionieren würde und Sie verzweifelt versuchen würden, Notfallmaßnahmen zu ergreifen. Selbst wenn Sie später Diagnosedaten wiederherstellen könnten, ist es unwahrscheinlich, dass Ihnen eine sich zuspitzende Auslastungskrise, die durch unkontrollierten Datenverkehr noch verschlimmert wird, ein klares Bild der Ursache vermitteln würde.
Und genau deshalb bezeichne ich CrowdHandler als unverzichtbaren Bestandteil Ihres Instrumentariums und nicht als Notlösung. Wenn Sie sich für unseren Warteraum entscheiden, geben Sie nicht auf und greifen nicht zu einer Schnelllösung: Sie nutzen vielmehr ein zusätzliches Diagnosewerkzeug, das Ihnen dabei hilft, einen klaren Kopf zu bewahren, Ihre Leistung kontinuierlich zu verbessern und gleichzeitig Kritik in den sozialen Medien einzudämmen.
Wenn du also darüber nachdenkst, CrowdHandler zu nutzen, komm bitte nicht mit eingezogenem Schwanz zu uns. Halte den Kopf hoch! Du bist Webentwickler. Du arbeitest an äußerst beliebten Projekten und setzt dich dafür ein, die Dinge noch besser zu machen. Du machst alles richtig.