Choosing between a fixed uWSGI worker pool and the cheaper subsystem
Decide when to use a fixed uWSGI worker pool versus the cheaper dynamic scaling subsystem for Python WSGI apps.
Loading…
ReadMeFeed / Community knowledge
#wsgi
Real questions. Useful conversations. Find the people who know your stack.
python
uwsgiCutting Backend Load with uWSGI's cache2 Response Cache
uWSGI's cache2 directive caches full WSGI responses in-process, keyed by path and method. Here's a minimal setup, how to verify hits, and the staleness and key-collision traps to avoid.
Using uWSGI Emperor Mode to Manage Multiple Vassal Apps with Zero‑Downtime Reloads
Learn how uWSGI Emperor mode watches a directory of vassal configs to spawn, reload, and isolate multiple WSGI apps with zero‑downtime updates.
Optimizing Memory for Multi-App Deployments with uWSGI lazy-apps
Learn how to use uWSGI's lazy-apps feature to reduce memory overhead in multi-app deployments by postponing application loading until the first request arrives.
Configure uWSGI's Cheaper Subsystem for Dynamic Worker Scaling
A practical guide to configuring uWSGI's cheaper subsystem for dynamic worker scaling in Python WSGI applications, covering prerequisites, algorithm selection, tuning parameters, verification steps, and recovery from common misconfigurations.
Flask app.logger messages missing from Gunicorn error logs
Confirm whether warnings emitted through app.logger.warning inside a Flask route appear in Gunicorn error output when no application logging handlers are explicitly configured. Flask's app.logger is a standard logging.Logger and does not automatically attach handlers or propagate to the root logger. Under Gunicorn or uWSGI, visibility depends on the WSGI ser
flaskuWSGI harakiri timeouts and client retries: preventing duplicate writes in WSGI handlers
Goal I run a WSGI application behind uWSGI (2.0.x) where POST endpoints perform database inserts. uWSGI's harakiri option aborts requests that exceed a configured time limit, and the client or upstream proxy may retry the same request afterward. Since uWSGI itself does not deduplicate retried requests, the WSGI handler can be invoked twice for what the user