Hi list, we're using a multi-worker, multi-threaded uwsgi setup with a uwsgi master and worker respawn limit (max-requests in the uwsgi config) to respawn uwsgi workers periodically (mostly to make sure we don't run into mem-leak issues).
While this is working just fine, we have the following issue / hope to improve: the request pattern on our servers can be divided into two very different work-loads: One set of requests occurs very frequently and is not processing (CPU/IO) intensive - and it's highly optimized. The other happens only sometimes but is very processing intensive. Since the one path is very optimized (basically because not much happens in the API), I would like to not count these requests against the respawn limit, to optimize use of in-memory caching. In my application it would be pretty straight-forward to tell uwsgi when would be a good time to respawn, but I don't know how I would do that - so, with a very long intro, here my question: Is it possible to [easily] send uwsgi a message that the worker from which the message is coming wants to be respawned? My current thinking is: one way I could simulate this is to divide the workers into two uwsgi services - one only serving processing intensive tasks, and the other the rest (this is easy, since we use nginx in front of uwsgi). The problem is that whether a request is going to be processing intensive does not [only] depend on the request URL, but also the state of the DB, so it's only a partial solution. Thanks for a great server and hopefully some insights ;) -Clemens
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
