Das deutsche Python-Forum

Aber im Live-Betrieb sind sicherlich mehr als 4 Clients gleichzeitig an Ressourcen interessiert.

Hallo,

da passt doch die alte Weisheit "premature optimization is the root of all evil".

Wie lange dauert denn ein Request-Response Zyklus bei deiner App? Wenn da nicht was mega rechenintensives oder ein massiver Datenbankzugriff dahinter liegt, dann ist das normalerweise nach ein paar Dutzend Millisekunden oder so durch und der Worker widmet sich dem nächsten Request. Wie viel Tausend Requests erwartest du denn pro Minute?

Außerdem setzt man genau darum nginx als Reverse-Proxy davor. Und wenn der ein gunicorn Serverprozess wirklich mal nicht mehr ausreichend, kannst du nginx auch als Load-Balancer konfigurieren. Mein Tipp: da kommst du sicher erst mal nicht hin, weil nicht nötig.

Gruß, noisefloor

Ich hab einen Server mit hundert parallelen Nutzern auf einem Thread, weil meine Datenbankabfragen asynchron laufen, ist das kein Problem. Dabei langweilt sich das System die meiste Zeit.
Bevor Du also keine Probleme bemerkst, brauchst Du Dir da keine Sorgen machen.

Zumal: Wenn es um die Anzahl der Worker geht ist diese 4 die da steht ja sehr leicht angepasst.

Ich weiß noch nicht wie lange ein Zyklus sein wird, da ich meine DB noch optimieren muss.

@Sirius: Du hast einen Worker mit einem Thread für 100 Nutzer laufen? Was lieferst du denn als response aus? Würden die Clients bei dynamischen Websites ewig warten?

Wie viele Threads sollte man einem Worker zuweisen?