Εrnst B. schrieb:
> Ich würde einen nginx oder caddy als reverse-proxy vor das Flask packen.
> Der kann sich dann um https-Verschlüsselung, Kompression usw. kümmern,
> und bei relativ statischen Sachen wie der Artikelliste auch die Anfragen
> aus einem Cache beantworten. Bei dynamischen Sachen kannst du damit auch
> ein Loadbalancing über mehrere python-Flasks machen.
All das würde ich womöglich auch tun -- wenn es denn sinnvoll ist. Nur
die manchmal geradezu reflexhafte Nutzung von Nginx als Cache erscheint
mit oft nicht ganz durchdacht -- denn wenn der Output bei NGinx ankommt,
ist er ja schon vollständig prozessiert und erzeugt. Da können andere
Caches, die von der Applikation gesteuert werden, viel bessere
Ergebnisse liefern, indem sie nur jenen Teil der Daten cachen, bei dem
sich das auch lohnt. So kann die Applikation nach meinen Erfahrungen
häufg viel stärker entlastet, und die ausgelieferten Daten gleichzeitig
aktueller gehalten werden. Nebenbei bemerkt: Python hat da eine
wundervolle Möglichkeit des Cachings einzelner Funktionen im
Standardmodul "functools", und für Flask gibt es zudem ein
Caching-Plugin mit dem wenig überraschenden Namen "Flask-Caching".
Wie dem auch sei, gelten hier natürlich dieselben drei Leitsätze wie bei
allen anderen Performanceoptimierungen:
1. "Premature optimization is the root of all evil" (Donald E. Knuth)
2. "Measure, don't guess" (Kirk Pepperdine)
3. "Make it work, make it right, make it fast" (Kent Beck)
Insofern halte ich es für sinnvoller, zunächst genau zu hinterfragen,
was der TO vor hat. Danach können wir ihm etwas Konkretes empfehlen...
und da könnten vielleicht auch gunicorn und gevent eine Rolle spielen?!
;-)