Wie erkennt man Performance-Risiken frühzeitig?

Performance-Probleme haben eine unangenehme Eigenschaft: Sie verstecken sich, solange die Umgebung klein ist. In der Entwicklung mit wenigen hundert Testdatensätzen und zwei Nutzern ist alles schnell. Zwei Jahre später, bei 1 Mio. Datensätzen und 200 Nutzern, ist es das nicht mehr, und jetzt ist der Umbau relevant und meistens teuer. Die interessante Frage ist deshalb, was sich schon am Anfang erkennen lässt.

Konstruktionen, die nicht mitwachsen

Einige Muster sind bei kleinen Datenmengen unauffällig und skalieren prinzipbedingt schlecht. Sie lassen sich direkt anhand der Konfiguration erkennen lange bevor sie messbar werden.

Synchrone Logik im Speicherprozess wächst linear mit der Nutzung: je öfter gespeichert wird, desto öfter muss der Nutzer warten. Ansichten, die über mehrere verknüpfte Tabellen filtern oder auf Textfeldern mit führendem Platzhalter suchen, werden mit der Datenmenge überproportional langsam/datenintensiv/teuer. Prozesse, die bei jeder Änderung triggern statt auf ausgewählte Felder gefiltert, erzeugen mehr Systemlast im Verhältnis zur Änderungsrate. Und N:N-lastige Datenmodelle machen jede dieser Abfragen zusätzlich langsam und schwerer.

Nichts davon braucht eine Messung. Es steht in den Definitionen: die Registrierung ohne Filterattribute, das fetchxml mit den Verknüpfungen, der Trigger auf alle Felder.

Der Moment, in dem man hinsehen sollte

Der beste Zeitpunkt für diese Prüfung ist vor dem ersten Produktivstart und danach vor jeder Auslieferung eines Inkremente, die neue Automatisierung oder Filterlogiken mitbringt. Es ist dieselbe Logik wie bei einer Code-Review: Die Bauart zu korrigieren kostet vor dem Start ein Bruchteil von dem, was es nach zwei Jahren Betrieb kostet die Umgebung wieder flott zu bekommen.

Konkret lohnt bei neuen Ständen regelmäßig der Blick auf vier Dinge: Kommen synchrone Schritte dazu, und müssen sie synchron sein? Haben neue Prozess-Trigger Filterattribute? Wie viele Abfragen erzeugt ein neues Formular beim Öffnen? Und reagieren zwei Automatisierungen jetzt auf dieselben Felder derselben Tabelle?

Hilfreich ist außerdem ein realistischer Testdatenbestand. Viele der genannten Muster bleiben unsichtbar, solange die Entwicklungsumgebung 300 Datensätze hat. Eine einmalige Befüllung der Kerntabellen auf produktionsnahe Größenordnungen macht aus mancher Bauart-Vermutung schon in der Entwicklung einen fühlbaren Effekt.

Frühwarnung im Betrieb

Für laufende Umgebungen gibt es Indikatoren, die vor den Beschwerden kommen. Wachsende Warteschlangen bei Systemaufträgen zeigen, dass die asynchrone Verarbeitung nicht mehr hinterherkommt. Häufige Zeitüberschreitungen einzelner Plug-ins stehen in den Ausführungsprotokollen, bevor Nutzer sie als Fehler sehen. Und eine Audit-Tabelle, die schneller wächst als die Nutzdaten, kündigt das Speicherproblem Monate vorher an.

Wer diese Werte quartalsweise überwacht, sieht Trends statt Ereignisse. Das ist der ganze Trick an der Frühzeitigkeit: nicht bessere Werkzeuge, sondern ein früherer Blick auf dieselben Stellen, an die man sonst erst nach der ersten schlechten Nutzererfahrung schaut.