Aus dem Blickwinkel eines Mathematikers – Last- und Performance-Themen in den Nachrichten

Keine Kommentare

Zwischen den großen Nachrichten dieses Novembers wie der irischen Finanzkrise und dem Konflikt in Korea gingen zwei kleine Nachrichten aus dem Bereich des bayerischen Schulwesens weitgehend unter: „Computer-Chaos an den Berufsschulen“ vom 16. und „Technik stoppt Abi-Umfrage“ vom 17. November, jeweils aus bayerischen Regionalzeitungen. Beide Meldungen zeigen beispielhaft die Bandbreite und die manchmal verheerenden Auswirkungen von Last- und Performance-Problemen bei modernen Computer-Systemen – eine Thematik, die nur selten in die Schlagzeilen der Mainstream-Medien gelangt.

„Computer-Chaos an den Berufsschulen” handelt von der Modernisierung des sogenannten Pädagogischen Netzes der Stadt München. Nach der Modernisierung wird das System langsamer, wenn sich nur zwei oder drei Schüler einloggen, „irgendwann geht gar nichts mehr“. Ungefähr 7.500 Schüler nutzen das System zum Training mit verschiedenster professioneller Software, es wird sogar für die Abschlussprüfungen benötigt. Daher überlegt man sogar, im Notfall auf das alte System zurückzustellen.

„Technik stoppt Abi-Umfrage” beschreibt die Überlastung einer öffentlichen Webseite, die als Plattform einer Umfrage unter allen bayerischen Abiturienten über deren Studienpläne dienen sollte. Nach nur wenigen Tagen brach die Webseite unter dem Ansturm von ca. 95.000 Besuchern zusammen. Jetzt wird geplant, statt einer vollständigen Erhebung nur Stichproben durchzuführen.

Diese beiden Nachrichten zeigen, dass Last- und Performance-Probleme unter sehr verschiedenen Rahmenbedingungen auftreten können: Ein Mal in einem großen, aber lokalen, Anwendungs-Netzwerk, das andere Mal bei einer Webseite. In beiden Fällen führt eine zu hohe Last zu Performance-Problemen oder sogar kompletten System-Ausfällen. Weiterhin gefährden in beiden Fällen die aufgetretenen Probleme das Erreichen des jeweiligen Unternehmens- bzw. Aktions-Zieles – und als öffentlich wahrgenommene Fehlschläge sind sie zusätzlich besonders peinlich. Schnelle Lösungen sind jeweils entweder teuer oder gar nicht verfügbar.

Da keine tieferen Details in den beiden Meldungen erwähnt werden, will ich nicht über die konkreten Gründe für die jeweiligen Performance-Probleme spekulieren, sondern stattdessen einige allgemeine Bemerkungen über mögliche Ursachen von Last- oder Performance-Problemen machen. Der größte und offensichtlichste Fehler ist, erst gar keine Last- oder Performance-Tests vorzusehen. Angesichts der potentiell katastrophalen Auswirkungen von Last- und Performance-Problemen scheint es verantwortungslos, diese Risiken zu ignorieren. Theoretische Überlegungen zu diesen Problemen sind ein guter Anfang, aber Überraschungen und noch unerkannte Zusammenhänge in der späteren produktiven Praxis sind eher die Norm als die Ausnahme. Daher sind meiner Meinung nach praktische Last- und Performance-Tests ein unverzichtbarer Bestandteil eines jeden IT-Projekts.

Sind Last- und Performance-Tests vorgesehen, so werden sie oft erst zum Ende des Projekts eingeplant; nach dem Abschluss der Entwicklungsphase oder sogar erst nach den funktionalen Tests. Nicht selten werden diese Tests dann aus Budgetgründen oder wegen zeitlicher Verzögerungen gekürzt oder gar ganz gestrichen, was erneut enorme Risiken in das Projekt hineinträgt. Nach unseren Erfahrungen bei codecentric ist es ohnehin am besten, mit Performance-Tests gleich zu Anfang eines Projektes zu beginnen. Sobald lauffähiger Code vorliegt, kann man ihn testen und auf Performance-Auffälligkeiten hin untersuchen. Und sobald der erste Geschäftsvorfall (GeVo) in auch nur rudimentärer Form vorliegt, kann mit Lasttests begonnen werden.

Da es letztendlich auf den realen Ernstfall ankommt – die Produktion – ist ein falsches Test-Konzept ein weiteres großes Risiko. Die getestete Last sowie die getesteten Geschäftsvorfälle müssen so realitätsnah wie möglich sein, um spätere böse Überraschungen zu vermeiden. Das Gleiche gilt für die Test-Umgebung – Hardware, Software und deren Konfiguration – die so produktionsnah wie möglich sein sollte. Im Idealfall kann man die Last- und Performance-Tests auf der späteren Produktionsumgebung durchführen.

In einigen Fällen kann es sehr schwierig bis unmöglich sein, eine realistische Last-Prognose zu erstellen, z.B. bei neuen Webseiten ohne vorhergehende Erfahrungen bzgl. Kunden- oder Nutzer-Verhalten. Dann muss man in den Tests einen umso größeren Bereich an möglichen Last-Szenarien bzw. Last-Verteilungen abdecken. Außerdem sollte das System flexibel und skalierbar sein, was ebenfalls getestet werden sollte. Wobei ausführliche Stress-Tests und ein flexibles, skalierbares System immer gute Ideen sind, selbst wenn man über konkrete Last-Vorhersagen verfügt.

Was auch immer die Ursachen für die Probleme in den geschilderten Fällen aus Bayern sein mögen, erst durch schlechte Erfahrungen in der Produktion auf Performance-Probleme aufmerksam zu werden, ist in jedem Fall sehr kostspielig. Ausreichend Zeit und Ressourcen in vorgelagerte Last- und Performance-Tests zu investieren, kann helfen, solche Risiken zu minimieren und mit ihnen umzugehen.

Dr. Raymond Georg Snatzke

Der promovierte Mathematiker Georg Snatzke ist seit 2007 bei codecentric. Sein Schwerpunkt sind alle Bereiche rund um das Thema Performance: Application Performance Management (APM), insbesondere mit AppDynamics, Performance-Analyse und -Optimierung sowie natürlich Lasttests. Georg ist zufrieden, wenn er schwarzen Rauch aus den Systemen aufsteigen sieht, die er unter Last setzen darf.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.