Ich habe heute versucht Tickets für Konzerte in der Elbphilharmonie zu kaufen. Nach meinen Erfahrungen beim Versuch mich für die Ticket-Verlosung zu registrieren, war ich skeptisch. Es hieß zwar die Infrastruktur der HamburgMusik sei nach dem Zusammenbruch bei der Verlosung entsprechend gewappnet, aber mir war aufgefallen, dass die Seite extrem viel Javascript und asynchrone Requests einsetzt. Tatsächlich waren die ersten Stunden des Online-Kartenverkaufs eine einzige Katastrophe.

Während ich versuchte Karten zu kaufen, habe ich die Seiten oberflächlich analysiert. Meiner Meinung nach hätte das System auch einem deutlich geringeren Ansturm nicht standgehalten. Das fängt schon bei der Programmübersicht an – ich denke das ist der normale Einstiegspunkt für Kartenkäufer – über der Liste der Konzerte ist ein Kalender, man kann dort nur monatsweise vor- und zurückblättern, dass Jahr kann nicht gewechselt werden. Eigentlich kein Problem, man blättert einfach 7 Monate vor und schon ist man im Eröffnungsmonat. Leider wird aber beim Blättern immer ein Request an den Server geschickt und der nächste Monat von dort geladen. Dem Benutzer wird während dieses asynchronen Request auf der Oberfläche nicht angezeigt, dass auf Daten vom Server gewartet wird – normalerweise geht das auch so schnell, dass man es gar nicht merkt. Nehmen wir aber an, dass 5000 Besucher vor dem Rechner sitzen und nahezu zeitgleich einen Monat vorblättern wollen, dann kommen nur dafür 5000 Requests zustande. Wenn das schon beim Kalender so ist, wird es an vielen Stellen ähnlich programmiert sein.

Die Seite ist sehr modern, aber es sieht nicht aus, als sei sie auch nur ansatzweise für einen großen Besucheransturm optimiert worden. Beim Laden einer Seite von shop.elbphilharmie.de habe ich gesehen, dass über Achtzig Javascript-Dateien geladen wurden. Achtzig Requests an den Server um eine einzige Seite zu laden, Stylesheets, Webfonts und Bilder sind darin noch nicht enthalten. Die Server konnten die vielen Anfragen nicht mehr beantworten, ein Teil der Javascript-Dateien wurde nicht geladen. Als Ergebnis sahen die Besucher Seiten mit großen Headerbildern, der Hauptnavigation und dem Fußbereich, die Inhalte fehlten komplett, denn die werden überwiegend mit Javascript generiert.
Die Seiten setzen AngularJS und jQuery ein, ich sah mehrmals AngularJS-Platzhalter in geschweiften Klammern. Zwischendurch konnte ich auch Fehlermeldungen des Internet Information Servers und von ASP.Net sehen. IIS und ASPX würde ich eher nicht benutzen, wenn ich mit tausenden Zugriffen pro Sekunde rechne. Ich kann mir nicht vorstellen, dass die Webseite und das Shopsystem irgendwann einen Stresstest bestanden haben.

Eine erste Maßnahme wäre, alle mittels AJAX geladenen Inhalte zu prüfen, sind sie wirklich nötig oder kann man die Zahl der Requests verringern? Oft würde es auch helfen den Benutzern zu zeigen, dass noch auf Daten vom Server gewartet wird – wenn der Ladebalken meines Browsers nicht mehr angezeigt wird und ich eine halb leere Seite sehe, klicke ich auf Reload und löse damit wieder viele Requests aus, die den Server belasten. Würde ich auf der Seite eine „Lade-Animation“ sehen, würde ich weiter warten. Unbedingt geprüft werden sollte, ob man wirklich über Achtzig Javascript-Dateien laden muss. Wenn der Server nicht viele Requests zeitgleich verarbeiten kann, wären wenige und dafür dann größere Dateien besser.

Mag sein, dass es nie wieder zu so einem Ansturm wie heute kommen wird, aber was heute passiert ist hätte man antizipieren können.

Ich habe übrigens am Nachmittag noch alle gewünschten Karten bekommen, obwohl die Server auch nach vier Stunden nicht ganz rund liefen und ich plötzlich wieder Internal Server Error gesehen habe.