Optimizing Gunicorn for Fast Clients

.
The only thing in the new versions worker_processes better to leave auto.

But you can also still see upstream response error (timedout).
In this case, we pay attention to Gunicorn.
There are different types of workers: Sync, Async, Gthread, Tornado, AsyncIO.

The most common configuration from setup manuals:
gunicorn --workers 3 wsgi:app

In this case, the following are used: Sync workers, for our example, as well as for most, this is the most suitable and universal option.

What is the optimal number of workers?
It is considered by the formula: (Number of processor cores)*2+1

In total, the configuration above is suitable for servers with one core, if there are more cores, then you can safely increase the number of workers according to the formula, but if not, increasing the number of workers will lead to a forced reboot Gunicorn'a system, because it will start to utilize the entire processor:
gunicorn.service: A process of this unit has been killed by the OOM killer

That is, for a server with 2 cores, the best configuration would be:
gunicorn --workers 5 wsgi:app

And also, Sync there are workers Gthread Class:
gunicorn --workers 5 --threads 2 wsgi:app
By specifying the thread parameter, workers automatically become class Gthread.

Threads will help increase productivity if the number of workers cannot be increased.
This setting is suitable for those who are not too demanding. CPUquick queries, I/O operations, SQLIn general, using threads helps reduce memory usage. Gunicorn'om.

Here's a little cheat sheet on optimization GunicornI hope it will be useful to someone!