Warum Ihre FastAPI- (oder Flask-)App bei hoher Auslastung eine schlechte Leistung erbringt

Zunächst möchte ich mich für den Titelköder entschuldigen? Aber ich habe dieses Problem gestern Abend herausgefunden und stehe immer noch unter den Auswirkungen des Dopaminrauschs. Das muss ich einfach teilen.

Dieser Text richtet sich an Einsteigerentwickler oder Datenwissenschaftler (nicht an erfahrene Python-Softwareentwickler) und ich werde ihn als Erzählung schreiben, oder mit anderen Worten als chronologische Abfolge der Ereignisse, wie sie passiert sind, und nicht als „technisches Papier“. (strukturiert in Problem, Lösung, Diskussion). Ich mag diesen Ansatz, weil er zeigt, wie die Dinge im wirklichen Leben passieren.

Erste Überlegungen

Diese Tests wurden auf GCP Cloud Run mit einem einzelnen Prozessor und einer 512 MB RAM-Maschine durchgeführt, und wir verwendeten Locust, ein unglaubliches Tool (für Python, LoL).

Wenn Sie außerdem bereits Leistungsprobleme bei einzelnen Anfragen auf Postman haben, empfehle ich Ihnen dringend, einen Blick auf dieses Repo zur Steigerung der FastAPI-Leistung von Kisspeter und dieses von LoadForge zu werfen.

Erste Testrunde

Mit einer einzigen Anfrage in Postman erreichte ich nach dem Start von Cloud Run eine Antwortzeit von etwa 400 ms. Nicht das Beste, aber völlig im akzeptablen Bereich.

Unser Lasttest ist ganz einfach: liest, schreibt und löscht in einer Tabelle (oder GETs, POSTs und DELETEs an die API-Endpunkte). 75 % Lesevorgänge, 20 % Schreibvorgänge, 5 % Löschvorgänge. Wir führen es 10 Minuten lang mit 100 gleichzeitigen Benutzern aus.

Am Ende haben wir eine durchschnittliche Reaktionszeit von 2 Sekunden erhalten, aber das Beunruhigendste daran ist, dass die durchschnittliche Zeit am Ende des Tests immer noch zunahm, sodass es sehr wahrscheinlich ist, dass die Zahl noch weiter ansteigt, bevor (und wenn) sie sich stabilisiert .

Ich habe versucht, es lokal auf meinem Rechner auszuführen, aber zu meiner Überraschung betrug die Reaktionszeit in Postman nur 14 ms. Beim Durchführen des Lasttests für 500 gleichzeitige Benutzer trat das Problem jedoch erneut auf? ...

Am Ende des Tests betrug die Reaktionszeit etwa 1,6 Sekunden und nahm immer noch zu, aber es kam zu einem Fehler, und der 95. Perzentil-Himmel schoss in die Höhe (und ruinierte das Diagramm =( ). Hier sind die Statistiken:

Warum beschleunigt ein Server, der mit 14 ms antwortet, plötzlich auf 1,6 Sekunden, wenn nur 500 gleichzeitige Benutzer vorhanden sind?

Mein Rechner ist ein Core i7, 6 Kerne, 2,6 GHz, 16 GB RAM, SSD. Es sollte nicht passieren.

Was mir einen guten Hinweis gab, waren meine Prozessor- und Speicherprotokolle ... Sie waren extrem niedrig!

Das bedeutet wahrscheinlich, dass mein Server nicht alle Ressourcen meines Rechners nutzt. Und wissen Sie was? Das war es nicht. Lassen Sie mich Ihnen ein Konzept vorstellen, das die überwiegende Mehrheit der Entwickler bei der Bereitstellung von FastAPI- oder Flask-Anwendungen für die Produktion vergisst: den Prozessarbeiter.

Gemäß getorchestra.io:

Server-Worker verstehen

Server-Worker sind im Wesentlichen Prozesse, die Ihren Anwendungscode ausführen. Jeder Mitarbeiter kann jeweils eine Anfrage bearbeiten. Wenn Sie mehrere Mitarbeiter haben, können Sie mehrere Anfragen gleichzeitig bearbeiten und so den Durchsatz Ihrer Anwendung steigern.

Warum Serverarbeiter wichtig sind

• Parallelität: Sie ermöglichen die gleichzeitige Bearbeitung von Anfragen, was zu einer besseren Nutzung der Serverressourcen und schnelleren Antwortzeiten führt.
• Isolation: Jeder Arbeiter ist ein unabhängiger Prozess. Wenn ein Arbeiter ausfällt, hat dies keine Auswirkungen auf die anderen und sorgt so für eine bessere Stabilität.
• Skalierbarkeit: Durch Anpassen der Anzahl der Worker können Sie Ihre Anwendung problemlos skalieren, um unterschiedliche Lasten zu bewältigen.

In der Praxis müssen Sie lediglich den optionalen Parameter --workers zu Ihrer Serverinitialisierungszeile hinzufügen. Die Berechnung, wie viele Worker Sie benötigen, hängt stark vom Server ab, auf dem Sie Ihre Anwendung ausführen, und vom Verhalten Ihrer Anwendung, insbesondere im Hinblick auf den Speicherverbrauch.

Danach habe ich lokal für 16 Arbeiter viel bessere Ergebnisse erzielt, die nach 10 Minuten auf 90 ms (für 500 gleichzeitige Benutzer) konvergierten:

Letzte Testrunde

Nachdem ich die Microservices mit der entsprechenden Anzahl von Workern konfiguriert hatte (ich habe 4 für meine Cloud Run-Instanz mit einem Prozessor verwendet), waren meine Ergebnisse in GCP unglaublich besser:

Der Endwert konvergiert am Ende des Tests im GCP-Server auf 300 ms, was zumindest akzeptabel ist. ?

Das obige ist der detaillierte Inhalt vonWarum Ihre FastAPI- (oder Flask-)App bei hoher Auslastung eine schlechte Leistung erbringt. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!