What are uwsgi threads used for?

Question

I see in a uwsgi.ini file there is a configuration

[uwsgi]
socket = 127.0.0.1:3031
chdir = /home/foobar/myproject/
wsgi-file = myproject/wsgi.py
processes = 4
threads = 2
stats = 127.0.0.1:9191

I understand that each request is served in a different process. Then what are threads used for ?

Solution 1

Both processes and threads can be used for increasing concurrency. Threads are cheaper than processes and use less resources, but may not always run in parallel because of Python GIL.

Also, quoting the uWSGI documentation:

There is no magic rule for setting the number of processes or threads to use. It is very much application and system dependent. Simple math like processes = 2 * cpucores will not be enough. You need to experiment with various setups and be prepared to constantly monitor your apps. uwsgitop could be a great tool to find the best values.

Solution 2

Adding an additional answer here due to a huge GOTCHA I had today.

Shared memory works across threads, but not processes. That is, if you have some module level thing like:

# mymodule
mycache = {}

mycache[key] = value

del mycache[key]

...

Deletes in one process will NOT be reflected in the cache of another process. However, deletes in one thread, if only one process is used, will persist across threads.

So if you are using shared memory like this, you have two options:

1. all caches should be "safe" and "read through" (ie on cache miss, try to load the real data)
2. always run threads=X but processes=1

Solution 3

Also with master process uwsgi is forking workers. That means, app is started once and memory is copied. So if cache data is inited on start uwsgi will fork copying cache. But keep in mind that if you update cache in some worker it wont change on other forked workers.

Comments

[Anubhav Agarwal]

does each process launches a thread to serve a request ? As in can I serve 8 concurrent requests from the above config ? Is there a difference between these 3 configs 4 process and 2 threads, 4 threads, 4 process ?

[Mikko Ohtamaa]

4 processes 4 threads can handle and scale up to 16 requests simultaneously. If the application bottleneck is waiting database IO then threading does not add penalty to Python. Furthermore each process takes a fixed amount of memory to spin up a new Python virtual machine. Threads do not do this.

[Cloud]

> Note that potentially blocking or long-running operations, such as I/O, image processing, and NumPy number crunching, happen outside the GIL. So is it better to use threads instead of process if the application is IO bound?