Ihre Anwendung ist langsam und die Nutzer beschweren sich? Lesen Sie das, bevor Sie einen stärkeren Server kaufen

Die Nutzer beschweren sich. Bildschirme laden endlos, ein Bericht dauert zwei Minuten, und am Montagmorgen funktioniert nichts so, wie es sollte. Jemand schlägt einen stärkeren Server oder einen größeren Cloud-Tarif vor. Sie kaufen ihn, zwei Monate lang wird es etwas besser, und dann ist alles wieder wie vorher. Nur die Rechnung ist jetzt höher, und zwar jeden Monat.

Das passiert, weil ein stärkerer Server in den meisten Fällen die Antwort auf die falsche Frage ist.

Warum ein stärkerer Server selten hilft

Stellen Sie sich einen Lagerarbeiter vor, der für jeden Artikel einer Bestellung einzeln ins Regal geht und zurückkommt. Bei einer Bestellung mit 400 Artikeln sind das 400 Wege. Sie können ihm einen schnelleren Gabelstapler kaufen, und er wird etwas schneller, aber die eigentliche Lösung ist, alles auf einem Weg zu holen.

Geschäftsanwendungen machen sehr oft genau das. Die häufigsten Ursachen für Langsamkeit liegen nicht in der Leistung des Servers, sondern darin, wie die Anwendung arbeitet:

• Hunderte Abfragen für einen Bildschirm. Die Anwendung fragt die Datenbank für jede Zeile einzeln ab, statt einmal für alle.
• Eine Datenbank ohne die richtigen Indizes. Um einen Datensatz zu finden, liest die Datenbank die ganze Tabelle. Solange die Tabelle klein ist, merkt es niemand. Nach fünf Jahren Daten merken es alle.
• Berichte, die alles laden. Die Anwendung holt alle Daten in den Speicher und filtert und summiert sie erst dann, statt das der Datenbank zu überlassen.
• Aufrufe externer Dienste nacheinander. Jeder Aufruf wartet auf den vorherigen, und so summieren sich die Sekunden.
• Nichts wird zwischengespeichert. Daten, die sich einmal am Tag ändern, werden bei jedem Öffnen eines Bildschirms neu berechnet.

Ein stärkerer Server macht jede dieser Stellen ein wenig schneller, und jeden Monat kommen mehr Daten hinzu. Deshalb kommt das Problem immer wieder.

Die Symptome zeigen, wo man suchen muss

Sie müssen kein Entwickler sein, um den Kreis einzugrenzen. Das kann eine Führungskraft selbst beobachten:

Was Sie bemerken	Wo das Problem meistens liegt
Nur manche Bildschirme oder Berichte sind langsam	Im Code oder in den Abfragen hinter diesen Bildschirmen
Alles wird langsamer, je mehr Daten es gibt	In der Datenbank: Indizes und die Art, wie Daten abgerufen werden
Es ist zu bestimmten Tageszeiten langsam	Gleichzeitig läuft etwas anderes: nächtliche Jobs, Backups, Datenimporte
Es ist seit der neuen Version langsam	Eine Änderung in dieser Version, und die findet man am schnellsten
Alles ist langsam, immer, für alle	Erst jetzt ist es Zeit, sich Server und Netzwerk anzusehen

Wie man Langsamkeit behebt: messen statt raten

Der teuerste Fehler ist, das zu reparieren, was jemand für das Problem hält. Die richtige Reihenfolge ist immer dieselbe:

1. MessenWo genau die Zeit bleibt
2. UrsacheDie drei größten Übeltäter
3. BehebenZuerst, was am meisten schmerzt
4. PrüfenZahlen vorher und nachher

1. Messen. Werkzeuge, die es für .NET-Anwendungen und SQL Server bereits gibt, zeigen genau, welcher Bildschirm langsam ist, wie viele Abfragen er an die Datenbank schickt und wie lange jede dauert. Danach wird nicht mehr geraten.
2. Ursache. Meist zeigt sich, dass zwei oder drei Dinge den Großteil des Problems verursachen. Die werden zuerst behoben.
3. Beheben. Man beginnt mit dem, was die Nutzer am stärksten spüren: Ein Bildschirm, den alle täglich öffnen, ist wichtiger als ein Bericht, der einmal im Monat läuft.
4. Prüfen. Dieselbe Messung vorher und nachher. Nicht “fühlt sich schneller an”, sondern “dieser Bildschirm hat sich in 8 Sekunden geöffnet, jetzt in einer”.

Solche Korrekturen sind oft eine Sache von Tagen oder Wochen, nicht von Monaten, und sie erfordern keinen Neubau der Anwendung. Einmal gemacht, werden sie nicht jeden Monat abgerechnet wie ein stärkerer Server.

Wann man doch einen stärkeren Server braucht

Manchmal schon. Wenn die Messung zeigt, dass die Anwendung vernünftig geschrieben ist und der Server ständig am Limit läuft, weil es immer mehr Nutzer und Arbeit gibt, dann ist ein stärkerer Server die richtige Entscheidung. Der Unterschied ist, dass Sie diese Entscheidung auf Grundlage von Zahlen treffen und nicht, weil es die schnellste Antwort ist.

Wie wir arbeiten

ProCoding ist ein .NET-Studio aus Split, Kroatien. Performance gehört zu den Dingen, die wir am häufigsten machen: in .NET-Anwendungen, ASP.NET Core, Blazor, Entity Framework, SQL Server und Azure.

Wir beginnen mit einer Messung Ihrer Anwendung, und Sie erhalten eine Liste der Ursachen, sortiert danach, wie sehr sie schmerzen. Danach beheben wir sie, oder Ihr Team tut es, wie es Ihnen besser passt. Der erste Schritt ist ein kostenloses 30-minütiges Gespräch, in dem wir die Symptome durchgehen und sehen, wo wir zuerst messen würden.