Verteilen von Python-/Flask-APIs in RHEL mit umfangreichen E/A-gebundenen Aufgaben ⇐ Linux

[Anonymous]

unten ist mein Anwendungsdesign. Wie Sie sehen können, hosten meine Back-End-Flaschen-/Python-APIs WebSocket-APIs für einige der Front-End-Aktionen. Das Ziel besteht darin, eine schnelle Kommunikation vom Front-End zum Back-End zu ermöglichen, da es in unserer Organisation Hunderte gleichzeitiger Benutzer gibt, die auf das Front-End zugreifen und Änderungen über das Front-End vornehmen. Dinge wie zum Beispiel:

• Klicken auf eine Schaltfläche, die einen Datensatz in unserer Back-End-Datenbank aktualisiert.
• Hinzufügen von Kommentaren zu Aufgaben, Antworten usw.,

Da die Benutzerbasis sehr groß ist und der WS eine super Geschwindigkeit bietet, um die Updates schnell vom Back-End zu erhalten, haben wir mit dem Hosten eines Websockets begonnen APIs. Aus diesem Grund sind wir von Apache zu Nginix gewechselt, da es native WS-Unterstützung bietet, um die Verbindung zu verbessern. Außerdem haben wir die Gunicorn-Eventlet-Kombination als Anwendungsserver gewählt, um den WSGI-Stil der Flask-APIs zu ermöglichen.
Jetzt besteht das Problem darin, dass die Aktualisierungen von Websocket-APIs in der Entwicklungsumgebung (die über die Pycharm-Benutzeroberfläche läuft, wenn Flask den Entwicklungsserver erstellt) ziemlich schnell sind. aber wenn es um eine gehostete Umgebung wie in der folgenden Architektur geht, ist es sehr langsam.

Mein jetziges Verständnis ist

da die Anzahl der Worker =1 die Konfiguration ist, die wir dem Eventlet geben mussten, kümmert sich ein Worker über grüne Threads um die ws-Verbindungen/Anfragen und führt in der Zwischenzeit auch die schweren IO-gebundenen Aufgaben aus. Wenn ich E/A-gebunden sage, meine ich die komplexen Datenbankabfragen und wir rufen Hunderttausende Datensätze ab. In manchen Fällen kann es zu Millionen von Datensätzen kommen, die Hunderttausende Datensätze aktualisieren/löschen usw.,
Daher ist der einzelne Worker nicht in der Lage, die 4-Kern-CPU effektiv zu nutzen. Daher ist es meine beste Wahl, dazwischen einen Nachrichtenbroker wie Redis einzuführen, der es dem Eventlet ermöglicht, mehr Worker zu verwenden, also 4. so dass die Belastung des Arbeiters um ein Viertel verringert wird und die Geschwindigkeit um das Vierfache oder sogar mehr erhöht werden kann.
Wie gesagt, das ist mein Verständnis, aber ich brauche hier die Hilfe von Experten.
Lassen Sie mich außerdem erklären, warum Flask APIs?
Früher bediente die Anwendung alles vom Back-End über Flask/Kinja Tempalte. Wir haben die Vorderseite verschoben, um zu reagieren, wie Sie in sehen können Das Designdiagramm, aber das Backend ist immer noch flask.
Wir werden bald auf eine schnelle API umsteigen, aber im Moment ist es keine Option. Auch die Umstellung der schnellen API könnte von der WSGI-Perspektive auf ASGI unterstützt werden, aber die Anwendungsserverkomponente (Eventlet / Uvincorn im Fall von FAST API), die auf IO-gebundene Aufgaben wartet, wird sich nicht ändern, daher denke ich, dass das Problem trotzdem angegangen werden muss.
Hinweis: Wir versuchen, einen Pool zu erstellen (Thread-Pool iguess, es gibt eine Option im Eventlet), um diesen Pool separat für die IO-gebundene Aufgabe zuzuweisen, aber dieser Ansatz ist noch in der Erprobung und hat bisher keine besten Ergebnisse in Bezug auf die Geschwindigkeit erbracht.