Softwareleistung: die wesentlichen Schritte, um mit der Optimierung zu beginnen

Wenn eine Anwendung langsamer wird, beginnen die meisten Teams instinktiv herumzubasteln. Ändern Sie eine Bibliothek, fügen Sie einen Cache hinzu, aktualisieren Sie eine größere Maschine. Es ist die falsche Reaktion und sie ist teuer, weil sie die Symptome angreift, bevor man die Krankheit versteht.

Leistung hat eine Methode. Es gibt eine richtige Reihenfolge der Schritte, und diese beginnt lange bevor Sie eine Codezeile berühren. Dieser Artikel richtet sich an diejenigen, die bereits verstehen, dass sie optimieren müssen und wissen möchten, wo sie diszipliniert beginnen müssen, ohne Wochen am falschen Ort zu verschwenden.

Ich werde dies nicht als eine Liste von Tricks betrachten. Tricks lösen konkrete Fälle und veralten schnell. Die Methode löst jeden Fall und erhält sich selbst.

Schritt 0: Definieren Sie, was „schnell“ bedeutet

Antworten Sie zunächst: Was ist akzeptabel? „Das System ist langsam“ ist kein umsetzbares Problem. „Die Eintragsseite muss bei 95 % der Anfragen in weniger als einer Sekunde antworten.“

Ohne ein Ziel weiß man nie, wann man aufhören muss. Optimierung ohne Ziel ist ein bodenloses Loch, man kann es immer schneller machen und es kostet immer mehr Aufwand, weniger zu gewinnen. Durch die Festlegung akzeptabler Reaktionszeitgrenzen, idealerweise nach Perzentilen, wird eine diffuse Empfindung in ein objektives Kriterium umgewandelt.

Dieser Schritt scheint bürokratisch, aber er ist es, was eine Optimierungsbemühung von einer endlosen Jagd unterscheidet. Dabei handelt es sich ebenso um ein Produkt- und Geschäftsgespräch wie um ein technisches Gespräch: Was „schnell genug“ ist, hängt davon ab, was der Benutzer zu tun versucht.

Schritt 1: Vor dem Umzug messen

Die wichtigste Regel dieser gesamten Disziplin: Man optimiert nicht, was man nicht misst. Ohne Instrumentierung ist jede Änderung eine Vermutung, und Vermutungen sind Zufall.

Instrumentieren Sie die Anwendung mit Metriken, strukturierten Protokollen und idealerweise verteilter Nachverfolgung. Das Ziel besteht darin, eine einfache Frage zu beantworten: Wo wird die Zeit verbracht? Die Antwort überrascht fast immer. Der Engpass liegt selten dort, wo die Intuition darauf hinweist.

Ein wiederkehrendes Muster: Das Team schwört, dass das Problem in der Sprache oder dem Framework oder den Instrumenten liegt, und stellt fest, dass 80 % der Zeit in einer einzelnen Datenbankabfrage liegt. Ohne Messung hätte dieses Team die gesamte Anwendung neu geschrieben und das Problem wäre immer noch da.

Das Werkzeug ist weniger wichtig als die Gewohnheit. Es könnte sich um eine vollständige Observability-Lösung oder ein gut platziertes Protokoll handeln. Was nicht fehlen darf, sind die Daten.

Schritt 2: Beseitigen Sie zuerst den größten Engpass

Anhand der vorliegenden Daten wird die Priorisierung offensichtlich. Es gibt eine starke Faustregel: Die meisten Verlangsamungen sind auf eine Minderheit von Ursachen zurückzuführen. Greife zuerst den Größten an.

Widerstehen Sie der Versuchung, zehn Mikrooptimierungen vorzunehmen, die in der Summe wenig ergeben. Finden Sie das Problem, das allein den größten Teil der Zeit ausmacht, und lösen Sie es. Der Gewinn durch die Beseitigung des Hauptengpasses ist in der Regel größer als der durch alle anderen Verbesserungen zusammengenommen.

Nachdem Sie den größten Wert ermittelt haben, messen Sie erneut. Der Engpass hat sich verschoben. Der zweitgrößte ist nun das neue Ziel. Leistung ist ein iterativer Prozess des Messens, Korrigierens und Behebens, nicht eine einzelne Anstrengung.

Schritt 3: Beginnen Sie mit der Datenbank

Bei den meisten Geschäftsanwendungen wird im Banking die meiste Zeit verschwendet. Deshalb verdient es vorrangige Aufmerksamkeit. Drei Prüfungen lösen einen Großteil der Probleme:

Fehlende Indizes. Abfragen, die die gesamte Tabelle scannen, weil ein Index für die gefilterte Spalte fehlt. Es ist der häufigste Fehler und am kostengünstigsten zu beheben.
Das N+1-Problem. Wenn der Code eine Abfrage für die Liste und dann eine zusätzliche Abfrage für jedes Element in der Liste durchführt. Für einhundert Artikel wurden einhundertein Anfragen gestellt. Das Problem wird gelöst, indem die entsprechenden Daten auf einmal geladen werden.
Abfragen, die zu viele Daten liefern. Das Durchsuchen der gesamten Tabelle zur Verwendung von drei Spalten ist eine Verschwendung von Datenbank, Netzwerk und Speicher.

Allein diese drei Korrekturen verändern die Geschwindigkeitswahrnehmung vieler Systeme. Und keiner von ihnen erfordert einen Technologiewechsel.

Schritt 4: Verwenden Sie den Cache mit Bedacht

Cache ist die verführerischste und gefährlichste Optimierung. Es bringt sofortige Vorteile und führt zu einer ganzen Klasse neuer Fehler: veraltete Daten.

Die goldene Regel: Locken Sie nur das, was leicht alt sein kann, ohne Schaden zu verursachen. Und definieren Sie immer explizit, wie der Cache ungültig gemacht wird. Cache ohne Invalidierungsstrategie ist keine Optimierung, sondern eine Zeitbombe.

Bei sensiblen Daten, Salden, Bestellstatus und Informationen, die sich ändern und deren Genauigkeit wichtig ist, sollten Sie es sich zweimal überlegen. In Systemen, die sich mit Geld oder Bürgerentscheidungen befassen, hat die Korrektheit der Daten Vorrang vor der Geschwindigkeit. Es hilft niemandem, schneller eine falsche Nummer anzuzeigen.

Es sei auch daran erinnert, dass der Cache auf mehreren Ebenen vorhanden ist: im Browser des Benutzers, in einer Zwischenschicht, auf dem Server, in der Bank. Jedes löst ein anderes Problem und hat seine eigenen Ungültigmachungskosten. Der Anfängerfehler besteht darin, Caches zu stapeln, ohne zu verstehen, wer auf was reagiert, und dann, wenn ein Datenelement schief geht, weiß niemand, in welcher Schicht es hängen geblieben ist. Zu einer guten Nutzung gehört es, bewusst zuzuordnen, wo der Cache arbeitet.

Schritt 5: Erst dann an die Infrastruktur denken

Das Aufrüsten einer größeren Maschine oder das Hinzufügen weiterer Instanzen ist oft der erste Schritt, den Teams unternehmen. Es sollte eines der letzten sein.

Die Skalierung der Infrastruktur ohne vorherige Behebung von Code- und Banking-Engpässen verschwendet Geld in das Problem. Sie zahlen mehr, um die gleiche ineffiziente Arbeit parallel zu erledigen. Die Kosten steigen und die Ineffizienz ist immer noch vorhanden, jetzt jedoch teurer.

Wenn die Codeoptimierung bereits durchgeführt wurde und die tatsächliche Grenze die Kapazität ist, kommt die Infrastruktur ins Spiel. Und der richtige Weg ist fast immer die horizontale Skalierung und das Hinzufügen von Instanzen, was erfordert, dass die Anwendung zustandslos ist. Dies ist eine architektonische Entscheidung, die es wert ist, frühzeitig getroffen zu werden, da eine spätere Korrektur mühsam ist.

Der Fehler, der alle Schritte ungültig macht

Es gibt einen kulturellen Fehler, der jedes Drehbuch sabotiert: Optimierung durch Intuition und Feiern, ohne das Ergebnis zu messen. Das Team verändert etwas, spürt, dass es schneller geworden ist und macht weiter. Ohne Messung nach der Veränderung weiß man nicht, ob es besser oder schlechter geworden ist oder nichts passiert ist.

Jede Optimierung braucht ein messbares Vorher und Nachher. Andernfalls verschieben Sie den Code nur und verdrehen ihn.

Die ehrliche Überlegung: Die meisten Leistungsprobleme erfordern keine Genies oder teuren Tools. Es erfordert Disziplin. Messen, priorisieren, den größten Engpass beheben, beheben. Teams, die dieser Reihenfolge folgen, lösen in Tagen, was Teams, die raten, nicht in Monaten lösen können.

Bei einer guten Leistung kommt es weniger auf das Talent als vielmehr auf den Prozess an. Wer diese Schritte verinnerlicht, hört mit dem Löschen von Bränden auf und fängt an, ihnen vorzubeugen.

Wenn Ihr Team weiterhin im Dunkeln auf die Lösung von Langsamkeit stößt, ist das Problem möglicherweise nicht technischer, sondern methodischer Natur. Es gibt weitere Artikel auf dem Blog über Qualität, Beobachtbarkeit und Skalierbarkeit, die diese Roadmap ergänzen. Wenn Sie sich darüber austauschen möchten, wie Sie dies in Ihrer Organisation gestalten können, lohnt sich ein Gespräch.