Softwareleistung: Was reale Fälle über Qualität lehren

Jedes Team hat die Szene erlebt. Das Produkt funktioniert in der Demo einwandfrei, besteht die Tests, gefällt dem Kunden. Drei Monate später beginnt die Anwendung bei echtem Datenverkehr zu stagnieren. Die Seiten brauchen Zeit. Der Support ist voller Beschwerden. Und niemand weiß genau, wo das Problem liegt.

Die Leistung bricht selten auf einmal zusammen. Es verschlechtert sich nach und nach, versteckt hinter Metriken, die bei hundert Benutzern komfortabel erschienen und bei hunderttausend nicht mehr tragfähig waren. Die Gefahr liegt nicht im offensichtlichen Höhepunkt, sondern in der stillen Erosion.

Ich möchte diesen Artikel nutzen, um Leistung als das zu betrachten, was sie wirklich ist: eine Qualitätsentscheidung, die direkte Auswirkungen auf den Cashflow, den Ruf und die Wachstumsfähigkeit hat. Nicht als Problem der „Codeoptimierung“, sondern als Symptom technischer Reife.

Leistung ist Qualität, keine Verschönerung

Es gibt eine Faulheitskultur, die „es zum Laufen bringen“ von „es schnell machen“ unterscheidet, als wäre das zweite ein optionaler Schritt für später. Diese Trennung ist falsch. Ein langsames System ist ein fehlerhaftes System, nur der Fehler äußert sich in einem Verlassen des Benutzers, nicht in einer Fehleranzeige.

Die These, die ich vertrete, ist einfach: Leistung ist eine nichtfunktionale Anforderung, die mit der gleichen Strenge behandelt werden muss wie eine funktionale Anforderung. Wenn Ihre Definition von „bereit“ das Verhalten unter Last nicht einschließt, ist Ihre Definition von „bereit“ unvollständig.

Ich habe das bei digitalen Regierungsprodukten schmerzlich gesehen. Ein öffentliches Dienstleistungsportal kann technisch einwandfrei sein und am Tag der Eröffnung der Registrierungs- oder Meldefrist dennoch scheitern. An diesem Tag ist der Zugang zu Spitzenzeiten die Regel und nicht die Ausnahme. Und genau an diesem Tag wird das Vertrauen des Bürgers gewonnen oder verloren.

Fall 1: Der Engpass lag in der Bank, nicht im Code

Ein Team verbrachte Wochen damit, die Anwendungsschicht neu zu schreiben, in der Überzeugung, dass das Problem in der Sprache lag. Sie haben Bibliotheken geändert, Funktionen umgestaltet und mit dem Framework gekämpft. Die Latenz ist etwas gesunken.

Als sie die Abfragen schließlich instrumentierten, kam die Wahrheit ans Licht: Eine einzelne Abfrage ohne Index durchsuchte bei jeder Anforderung die gesamte Tabelle. Das Problem war nie die Anwendung. Es war das berühmte getarnte N+1, multipliziert mit jedem Eintrag auf einer Liste, die jeden Monat länger wurde.

Der Unterricht ist nicht technisch, sondern kulturell. Ohne Beobachtbarkeit, Metriken, Traces, strukturierte Protokolle können Sie nicht optimieren, vermuten Sie. Und Vermutungen sind teuer. Das Team verbrachte Wochen am falschen Ort, weil es keine Möglichkeit hatte zu erkennen, wo tatsächlich Zeit verbraucht wurde.

Es bleibt die Regel: Vor dem Umzug messen. Optimierung ohne Messung ist Aberglaube.

Fall 2: Der Cache, der gelogen hat

Ein anderes Produkt hat Ihre Ladeprobleme durch aggressives Caching gelöst. Es hat wunderbar funktioniert, bis die Daten veraltet waren. Nutzer sahen alte Salden, bereits geänderte Zustände, Informationen, die nicht der Realität entsprachen.

Leistung wurde auf Kosten der Korrektheit gewonnen. Und Korrektheit ist in Systemen, die sich mit Geld oder Bürgerentscheidungen befassen, nicht verhandelbar.

Beim Lernen geht es hier um explizite Kompromisse. Cache ist eines der leistungsstärksten Tools auf dem Markt, aber jeder Cache ist ein Glücksspiel, bei dem die Daten möglicherweise etwas veraltet sind. Bei dieser Wette muss es sich um eine bewusste, dokumentierte Entscheidung mit einer klaren Entwertungsstrategie handeln, nicht um eine unter Druck angewendete Lösung.

Der häufige Fehler besteht darin, Cache als Magie zu behandeln. Wenn das Team nicht genau versteht, was wie lange und warum zwischengespeichert wird, ist das Caching keine Optimierung mehr und wird zu einer Quelle von Fehlern, die schwer zu reproduzieren sind.

Fall 3: Das System skalierte vertikal, bis es nicht mehr funktionieren konnte

Es gibt ein klassisches Muster eines wachsenden Unternehmens: Der Verkehr nimmt zu, die Antwort besteht darin, eine größere Maschine zu mieten. Es funktioniert einmal, zweimal, dreimal. Bis zu dem Tag, an dem es keine größere Maschine mehr gibt oder sie absurd teuer ist.

Ein Fall, den ich verfolgt habe, hatte genau diese Grenze. Das System war monolithisch, der Zustand wurde im lokalen Speicher gespeichert, was die parallele Ausführung mehrerer Instanzen verhinderte. Die horizontale Skalierung erforderte ein Umschreiben der Art und Weise, wie die Anwendung Sitzungen speicherte.

Die Korrektur war nicht heroisch. Dadurch wurde der Zustand externalisiert, die Anwendung wirklich zustandslos gemacht und ein Balancer in den Vordergrund gestellt. Von da an wurde das Wachstum zu einer Frage des Hinzufügens von Instanzen, etwas, das die Cloud-Infrastruktur fast automatisch erledigt.

Die strategische Vision: Die Architektur setzt die Wachstumsgrenze lange vor dem Code. Entscheidungen, die frühzeitig getroffen werden, wenn das Produkt klein ist, bestimmen, wie teuer die Skalierung sein wird, wenn es groß ist.

Was haben diese Fälle gemeinsam?

Keines dieser Probleme war ursprünglich ein Sprach- oder Frameworkproblem. Bei allen handelte es sich um Probleme der Diagnose, des Kompromisses und der Architektur. Reife Teams sind nicht diejenigen, die den schnellsten Code schreiben, sie sind diejenigen, die verstehen, wo Zeit investiert wird, und bewusste Entscheidungen darüber treffen, wo sie Aufwand investieren.

Drei Grundsätze gelten für die drei Fälle:

Vor der Optimierung messen. Ohne Daten korrigieren Sie die falsche Stelle.
Kompromisse müssen explizit sein. Bei jeder Optimierung wird eine Sache gegen eine andere ausgetauscht. Wissen Sie, was Sie austauschen.
Architektur ist Schicksal. Die Kosten der Skalierung werden durch strukturelle Entscheidungen definiert, nicht durch Implementierungsdetails.

Die Falle der vorzeitigen und späten Optimierung

In der Technik gibt es ein bekanntes Sprichwort, dass vorzeitige Optimierung die Wurzel vieler Übel ist. Es stimmt, aber es ist zu einer Ausrede geworden. Teams verwenden diesen Ausdruck, um die Leistung zu ignorieren, bis das Problem in die Produktion übergeht.

Der richtige Punkt liegt in der Mitte. Optimieren Sie nicht, was niemand nutzt. Setzen Sie jedoch frühzeitig akzeptable Reaktionszeiten und messen Sie sich daran. Sie müssen nicht alles optimieren, Sie müssen wissen, wann etwas die Grenze zum Inakzeptablen überschritten hat.

Die ehrliche kritische Betrachtung lautet: Die meisten Leistungsdesaster sind nicht auf mangelnde technische Kenntnisse zurückzuführen. Es liegt an einem Mangel an Sichtbarkeit und Kultur. Teams, die nicht messen, die nicht über die erwartete Last sprechen, die die schwersten Abfragen nicht überprüfen, werden dieselben Fehler wiederholen, unabhängig vom verwendeten Stack.

Leistung als Geschäftsvorteil

Für diejenigen, die führen, lohnt es sich, die Logik umzukehren. Leistung ist kein technischer Aufwand, sondern ein geschäftlicher Hebel. Ein schnelles Produkt wandelt mehr um, behält mehr und kostet weniger im Betrieb. Ein System, das ohne Neuschreiben skaliert werden kann, gibt dem Team die Freiheit, etwas aufzubauen, statt Probleme zu löschen.

Im öffentlichen Sektor ist die Argumentation sogar noch direkter: Ein digitaler Dienst, der Spitzenlasten bewältigen kann, ist ein Dienst, der seine Funktion erfüllt. Eines, das auf den wichtigsten Tag fällt, zerstört das Vertrauen, das über Jahre hinweg aufgebaut wurde.

Softwarequalität ist letztlich die Summe vieler kleiner Entscheidungen, die ernst genommen werden. Leistung ist eines der sichtbarsten Dinge und eines der Dinge, die Produkte, die wachsen, am meisten von Produkten unterscheiden, die nur überleben.

Wenn in Ihrem Unternehmen Leistungseinbußen auftreten, ohne die Ursache zu verstehen, besteht der erste Schritt fast nie darin, die Technologie zu ändern, sondern darin, Sichtbarkeit zu erlangen. Auf dem Blog gibt es weitere Artikel zu Qualität, Architektur und Skalierbarkeit, die sich eingehender mit diesem Weg befassen. Wenn dies ein Problem ist, das Sie nachts wach hält, lohnt es sich, darüber zu sprechen.