Python-Anwendung langsam: Was vor dem Skalieren zu prüfen ist
Wenn eine Python-Anwendung unter Last langsamer wird, messen Sie zuerst einen konkreten Arbeitsschritt des Nutzers. Klären Sie, ob die Zeit für Datenabfragen, Berechnungen, das Warten auf ein anderes System oder die Anzeige des Ergebnisses benötigt wird. Auf dieser Grundlage lassen sich die Kosten einer Verbesserung mit den Kosten zusätzlicher Serverressourcen vergleichen.
Wenn Verzögerungen bereits die Annahme von Bestellungen oder die Arbeit des Teams verhindern, sollte der Dienstleister zunächst den Betrieb stabilisieren. Vorübergehend mehr Ressourcen bereitzustellen, kann dabei helfen. Vereinbaren Sie gleich, wie die Wirkung geprüft wird und wann über die weitere Lösung entschieden wird. So wird aus einer Sofortmaßnahme kein dauerhafter Kostenposten ohne klare Begründung.
Was dauert für den Nutzer zu lange?
Konkretisieren Sie die Meldung „Das System ist langsam“ anhand einer Aufgabe: die Bestellliste öffnen, ein Formular speichern, ein Produkt suchen oder einen Bericht erstellen. Halten Sie fest, wann das Problem auftritt, wen es betrifft und ob zuvor die Anwendung geändert wurde, die Zugriffszahlen gestiegen sind oder die Datenmenge zugenommen hat. Das hilft, die Situation nachzustellen. Dass zwei Ereignisse zeitlich zusammenfallen, erklärt allerdings noch nicht die Ursache.
Der Dienstleister sollte diesen Vorgang vom Klick bis zum Ergebnis auf dem Bildschirm nachvollziehen. Ein Teil der Verzögerung kann im Browser oder in der Netzwerkverbindung entstehen. Liegt die Verzögerung auf dem Server, muss ermittelt werden, wie viel Zeit die Anwendung, die Datenbank und externe Dienste jeweils benötigen. Andernfalls bezahlen Sie womöglich für den Ausbau einer Komponente, die das Problem gar nicht verursacht.
Der Bericht sollte Antwortzeiten, Anfragevolumen, Fehler und die Auslastung der Ressourcen zeigen. Diese vier grundlegenden Bereiche beschreibt das Google-SRE-Handbuch zum Monitoring. Auch das Ergebnis muss stimmen: Eine schnelle Fehlermeldung bedeutet noch nicht, dass ein Mitarbeiter seine Aufgabe erledigt hat.
Wie viele Anfragen pro Sekunde muss die Anwendung verarbeiten?
Eine Anfrage ist ein einzelner Aufruf des Servers, etwa um Daten für eine Tabelle abzurufen. Eine Nutzeraktion kann mehrere solcher Aufrufe erfordern. Die Zahl der Anfragen pro Sekunde, kurz RPS für „Requests per Second“, entspricht deshalb weder der Nutzerzahl noch der Zahl abgeschlossener Bestellungen.
Für die Kapazitätsplanung brauchen Sie ein Bild der tatsächlichen Nutzung: Wie viele Personen arbeiten gleichzeitig, was tun sie und wie verändert sich die Last zu Spitzenzeiten? Ein Test, der lediglich „Server läuft“ zurückgibt, sagt wenig darüber aus, wie viele Bestellungen sich speichern lassen, wenn zugleich Berechtigungen, Lagerbestände und Verbindungen zu anderen Systemen geprüft werden.
Legt ein Dienstleister ein Testergebnis vor, fragen Sie nach dem Messumfang. Es muss klar sein, ob das Ergebnis einen Anwendungsprozess, einen Server oder mehrere Server zusammen betrifft. Ebenso wichtig sind die getesteten Daten und Funktionen, die Zahl erfolgreich abgeschlossener Vorgänge und die Antwortzeiten. Hinzu kommen die Kosten der Testumgebung. Ohne diese Angaben lässt sich eine RPS-Zahl kaum für eine Budgetentscheidung nutzen.
Was lässt sich verbessern, bevor weitere Server hinzukommen?
Die Messungen sollten zeigen, welche Arbeiten nötig sind. Die Django-Dokumentation zur Leistungsoptimierung empfiehlt, zuerst das Ziel festzulegen und das Verhalten der Anwendung zu messen. Welche Wirkung andere Werkzeuge oder Softwareversionen haben, muss im jeweiligen System geprüft werden.
Daten abrufen und verarbeiten
Bei einer langsamen Bestellliste lohnt sich ein Blick darauf, wie viele Daten die Anwendung abruft und wie oft sie die Datenbank abfragt. Möglicherweise lädt sie die gesamte Historie, obwohl der Nutzer nur einen Ausschnitt sieht, oder führt für jede Zeile eine eigene Abfrage aus. Die Django-Empfehlungen für Datenbankzugriffe behandeln die Messung von Abfragen, das Vermeiden unnötiger Zugriffe und die Auswahl von Indizes. Das sind Datenstrukturen, die das Auffinden von Daten erleichtern.
Lassen Sie sich bei der Abnahme zeigen, welche Datenabfragen oder Berechnungen geändert wurden und wie sich das auf denselben Arbeitsschritt auswirkt.
Vorhandene Ergebnisse wiederverwenden
Ein Cache, also ein Zwischenspeicher, hält bereits abgerufene Daten oder berechnete Ergebnisse zur erneuten Verwendung bereit. Das kann helfen, wenn viele Personen ähnliche Daten lesen und deren wiederholte Bereitstellung aufwendig ist. Dafür muss feststehen, wie lange ein Ergebnis veraltet sein darf und wann es aktualisiert wird. Diese Grenzen erläutert Microsoft am Cache-Aside-Muster.
Bei einem historischen Bericht kann eine andere Verzögerung bei der Aktualisierung vertretbar sein als bei der Prüfung der Produktverfügbarkeit vor einem Verkauf. Bei der Entscheidung über einen Cache zählen daher auch die Folgen veralteter Werte. Zu den Kosten gehören außerdem der Betrieb des zusätzlichen Dienstes und der Aufwand, wenn ein Ergebnis erneut erzeugt werden muss.
Aufgaben, die warten können, im Hintergrund ausführen
Ein großer Datenexport kann im Hintergrund laufen: Der Nutzer stößt ihn an und erhält die Datei nach Abschluss. Das ist sinnvoll, wenn das Ergebnis nicht sofort benötigt wird. Der Status muss sichtbar sein; Fehler müssen gemeldet werden, und ein sicherer erneuter Versuch muss möglich sein.
Dass eine Aufgabe schnell in die Warteschlange aufgenommen wird, sagt noch nichts darüber aus, wie schnell sie fertig ist. Treffen über längere Zeit mehr Aufgaben ein, als verarbeitet werden können, wächst die Warteschlange und damit die Wartezeit. Messen Sie bei der Abnahme deshalb auch die Zeit vom Auslösen der Aufgabe bis zum fertigen Ergebnis. Für Vorgänge, die eine sofortige Bestätigung erfordern, etwa ob eine Reservierung gespeichert wurde, muss gesondert vereinbart werden, wie sie ablaufen.
Wann lohnt sich zusätzliche Serverkapazität?
Mehr Ressourcen sind sinnvoll, wenn die Messungen zeigen, dass fehlende Kapazität die benötigten Vorgänge ausbremst. Möglich sind ein leistungsfähigerer Server oder zusätzliche Kopien der Anwendung, auf die die Anfragen verteilt werden. Prüfen Sie dabei, ob die übrigen Teile des Systems die höhere Last bewältigen können.
Greifen alle Kopien auf dieselbe überlastete Datenbank zu, beseitigen weitere Kopien diesen Engpass nicht. Ebenso verkürzt mehr Rechenleistung auf dem Anwendungsserver allein nicht die Wartezeit auf einen langsamen externen Dienst. Der mögliche Nutzen sollte sich in einem Test des gesamten benötigten Ablaufs zeigen.
Vergleichen Sie die Varianten vor der Angebotsfreigabe anhand desselben Ziels: Wie schnell und mit wie vielen Fehlern soll die Anwendung die vereinbarten Aufgaben bei der erwarteten Nutzung ausführen? Berücksichtigen Sie neben den Umsetzungskosten auch die monatlichen Betriebskosten, den Aufwand für zusätzliche Dienste und die Möglichkeit, Ausgaben bei sinkender Last wieder zu reduzieren. Auch wenn Ressourcen automatisch hinzugefügt werden, brauchen Sie eine vereinbarte Kostengrenze und einen Plan für den Fall, dass sie erreicht wird.
Müssen Sie Django oder Flask durch FastAPI ersetzen?
Dass eine Anwendung mit Django oder Flask entwickelt wurde, ist für sich genommen kein Grund, sie neu zu schreiben. Beide sind Werkzeuge zur Entwicklung von Webanwendungen. Ein Wechsel zu einem anderen Werkzeug wie FastAPI sollte einen gemessenen Engpass beheben. Berücksichtigen Sie auch, was es kostet, die vorhandenen Funktionen neu zu entwickeln, sie zu testen und die Anwendung später zu warten.
Häufig wird asynchrone Verarbeitung vorgeschlagen: Das Programm kann andere Aufgaben erledigen, während es auf Daten wartet. So lässt sich die Wartezeit nutzen. Aufwendige Berechnungen werden dadurch allein jedoch nicht schneller. Sie gleichzeitig auf mehreren Prozessorkernen auszuführen, ist ein anderer Mechanismus, für den die Arbeit passend aufgeteilt werden muss. Den Unterschied erklärt die FastAPI-Dokumentation.
Auch Django unterstützt asynchronen Code. Der Nutzen hängt allerdings davon ab, wie die Anwendung betrieben wird und welche Bibliotheken sie verwendet. Prüfen Sie zunächst die Möglichkeiten des vorhandenen Systems. Ist der Umbau eines Teils sinnvoll, sollte sich sein Umfang aus den Messungen ergeben, nicht aus einer Rangliste beliebter Technologien.
Wie prüfen Sie das Ergebnis und nehmen die Arbeit ab?
Vereinbaren Sie vor der Änderung ein Testszenario: Aufgaben der Nutzer, Datenmenge, gleichzeitige Zugriffe und die Bedingungen für die Kommunikation mit anderen Systemen. Wiederholen Sie den Test danach in einer vergleichbaren Umgebung. Die k6-Dokumentation zu Lasttests empfiehlt, die übliche Nutzung nachzubilden und das System lange genug zu beobachten, um sein Verhalten unter Last zu erkennen. Für Ihr Unternehmen kann zusätzlich ein eigenes Szenario für Verkaufsspitzen nötig sein.
Verlassen Sie sich bei der Abnahme nicht allein auf den Durchschnitt. Hilfreich ist zum Beispiel der p95-Wert für erfolgreich abgeschlossene Vorgänge: 95 % davon sind innerhalb der angegebenen Zeit fertig. Die übrigen können länger dauern. Bewerten Sie deshalb auch die Fehler und die längsten Verzögerungen. Die Zielzeit sollte zur Aufgabe passen: Für das Speichern eines Formulars können andere Anforderungen gelten als für die Erstellung eines umfangreichen Berichts.
Der Abnahmebericht sollte die Ergebnisse vor und nach der Änderung, die Bedingungen beider Messungen, verbleibende Einschränkungen und die laufenden Kosten zeigen. Bei einem Cache ist auch der Betrieb ohne gespeicherte Ergebnisse zu prüfen, bei Hintergrundaufgaben die Wartezeit bis zum Abschluss. Legen Sie außerdem fest, wer bei einer Verschlechterung nach der Einführung reagiert und wie Sie zur vorherigen Version zurückkehren können.
Für ein erstes Gespräch reichen eine Beschreibung der betroffenen Arbeitsschritte, Beispiele für das Auftreten des Problems und Angaben zum erwarteten Anstieg der Nutzung. Wenn Sie die Weiterentwicklung und Wartung einer bestehenden Anwendung beauftragen, vereinbaren Sie zunächst eine Untersuchung mit einem Vorschlag für die nötigen Arbeiten und einer Möglichkeit, das Ergebnis zu prüfen. Auf dieser Grundlage können Sie entscheiden, für welche Änderung sich die Ausgabe lohnt.
