SeovantisSeovantis
+49 15679 281048Anfrage stellen
High-Performance2026-10-05

Langsame Software: Den Engpass messen und gezielt ersetzen

Stephanie Escarciga (öffnet in neuem Tab)

„Das System ist langsam“ ist keine Diagnose. Die Ursache kann in der Datenbank, einer Schnittstelle, der Infrastruktur oder einer einzelnen Komponente liegen. Erst wenn der Engpass gemessen ist, lässt er sich gezielt beheben.

Stand: Oktober 2026

Wie Software langsam wird

Eine Anwendung wird selten plötzlich langsam. Meist geschieht es schleichend:

  • Datenmengen wachsen über Jahre.
  • Schnittstellen und externe Dienste kommen hinzu.
  • Hintergrundverarbeitungen werden umfangreicher.
  • Mehr Nutzer arbeiten gleichzeitig.

Aus Sekunden werden Minuten. Für den Einzelnen wirkt das lange erträglich, über viele Vorgänge am Tag summiert es sich.

Was sich messen lässt

„Langsam“ ist ein Eindruck. Messbar sind:

  • Antwortzeit: wie lange ein Vorgang vom Auslösen bis zum Ergebnis dauert
  • Durchsatz: wie viele Vorgänge pro Sekunde oder Stunde verarbeitet werden
  • Ressourcen: Rechenzeit, Arbeitsspeicher, Datenträger- und Netzwerkzugriffe
  • Wartezeit: wie lange die Anwendung auf Datenbank oder Schnittstellen wartet

Bei Antwortzeiten verdeckt der Durchschnitt die Ausreißer. Aussagekräftiger sind Perzentile: Der Wert p95 gibt an, wie lange die langsamsten 5 Prozent der Vorgänge mindestens dauern. Genau diese Vorgänge bemerken Nutzer.

Gemessen wird mit Profilern, die zeigen, in welcher Funktion die Rechenzeit liegt. Dazu kommen Tracing-Werkzeuge wie OpenTelemetry, die einen Vorgang über mehrere Dienste verfolgen. Für Datenbanken zeigt der Ausführungsplan (EXPLAIN), wie eine Abfrage tatsächlich abgearbeitet wird.

Warum die Messung entscheidet

Das Amdahlsche Gesetz beschreibt, wie viel eine Beschleunigung insgesamt bringt. Maßgeblich ist der Anteil des beschleunigten Teils an der Gesamtzeit.

Ein Beispiel: Ein Vorgang dauert 10 Sekunden. Eine Komponente braucht davon 8 Sekunden. Wird diese Komponente auf 1 Sekunde beschleunigt, dauert der Vorgang 3 statt 10 Sekunden. Wird stattdessen ein Teil mit 1 Sekunde Anteil doppelt so schnell, dauert der Vorgang 9,5 Sekunden.

Deshalb bringt eine Verbesserung an einer leicht erreichbaren, aber wenig genutzten Stelle kaum etwas. Und ohne Messung vorher lässt sich hinterher nicht belegen, ob eine Änderung gewirkt hat.

Wo die Zeit typischerweise verloren geht

Datenbank:

  • Abfragen innerhalb von Schleifen statt einer gebündelten Abfrage (das sogenannte N+1-Problem)
  • fehlende oder ungeeignete Indizes, sichtbar im Ausführungsplan
  • große Datenmengen, die ungefiltert übertragen und erst in der Anwendung aussortiert werden

Anwendung:

  • Berechnungen, die bei jedem Aufruf neu erfolgen, obwohl sich das Ergebnis nicht ändert
  • Algorithmen, deren Laufzeit mit der Datenmenge überproportional wächst
  • Speicherverbrauch, der mit der Datenmenge steigt, bis das System swappt oder der Prozess mit Out-of-Memory abbricht

Schnittstellen:

  • viele Einzelaufrufe statt gebündelter Übertragung
  • synchrones Warten auf externe Dienste mitten in einem Vorgang
  • Antworten mit deutlich mehr Daten als benötigt

Infrastruktur:

  • Rechenzeit, Speicher oder Datenträger am Limit
  • Hintergrundverarbeitungen, die zur Hauptarbeitszeit laufen
  • Zwischenspeicher (Caches), die fehlen oder veraltete Daten liefern

Neubau oder einzelne Komponente

Die erste Reaktion auf langsame Software ist oft: „Das muss neu gebaut werden.“ Ein Neubau löst aber keine unbekannte Ursache. Er verlagert sie in ein neues, größeres Vorhaben.

Häufig zeigt die Messung: Der größte Teil der Wartezeit entsteht an einer oder wenigen Stellen. Dann lässt sich genau dieser Teil ersetzen, hinter derselben Schnittstelle. Der Rest der Anwendung bleibt unverändert. In der Softwareentwicklung heißt dieses Vorgehen Strangler-Fig-Muster: Ein System wird Stück für Stück erneuert, ohne dass der Betrieb unterbrochen wird.

Damit der neue Teil sich genauso verhält wie der alte, braucht es automatische Tests. Sie halten das heutige Verhalten fest. Alter und neuer Code erhalten dieselben Eingaben, und die Ergebnisse werden verglichen.

Manchmal liegt die Grenze in der Programmiersprache selbst. Das ist etwa der Fall bei Garbage-Collection-Pausen, bei Speicherfehlern in C oder C++ oder bei begrenzter Parallelverarbeitung. Dann wird der Teil in einer anderen Sprache neu entwickelt, zum Beispiel in Rust, bei begrenzter Parallelverarbeitung auch in Go.

Was eine messbare Anforderung enthält

Aus „Die Software ist langsam“ wird eine prüfbare Anforderung, wenn vier Angaben feststehen:

  • Vorgang: welche Funktion oder Verarbeitung zu langsam ist
  • Ausgangswert: wie lange sie heute dauert
  • Rahmenbedingungen: mit welchen Datenmengen und unter welchen Bedingungen gemessen wird
  • Zielwert: welche Antwortzeit, welcher Durchsatz oder welcher Speicherverbrauch erreicht werden soll

Ein Beispiel: Ein Monatsbericht braucht heute 18 Sekunden. Unter denselben Testbedingungen soll er höchstens 3 Sekunden brauchen. Nach der Änderung wird erneut gemessen. Damit steht fest, ob das Ziel erreicht ist.

Seovantis schreibt den gemessenen Engpass neu, in derselben oder einer anderen Sprache, mit vereinbartem Verhalten und, wo vereinbart, einem messbaren Zielwert: Komponenten neu entwickeln

Quellen

Passende Leistung

High-Performance

Ein ähnliches Vorhaben?

Schildern Sie kurz Ihre Ausgangslage. Ich melde mich innerhalb eines Werktags.

Anfrage stellen