Оптимизация Gunicorn для быстрых клиентов

Возьмем за пример стек Nginx + Gunicorn + Django.
Бывает, что при наплыве трафика, Nginx отвечает ошибкой 5хх, а в логе Django ошибок нет.

Вы также можете увидеть, что Nginx говорит: «not enough workers«. Это фиксится очень просто и уже есть довольно старая статья на Хабре, которая всё ещё актуальна: Ускоряем Nginx за 5 минут / Хабр (habr.com).
Единственное, что в новых версиях worker_processes лучше оставить auto.

Но Вы также можете всё ещё видеть upstream response error (timedout).
В таком случае мы обращаем внимание на Gunicorn.
Есть разные виды воркеров: Sync, Async, Gthread, Tornado, AsyncIO.

Самая распространённая конфигурация из мануалов по настройке:
gunicorn --workers 3 wsgi:app

В данном случае используются Sync воркеры, для нашего примера, а также для большинства это наиболее подходящий и универсальный вариант.

Какое количество воркеров оптимально?
Считается формулой: (Количество ядер процессора)*2+1

Итого, конфигурация выше подходит для серверов с одним ядром, если ядер больше, то можно смело увеличивать количество воркеров по формуле, но если нет, увеличение количества воркеров приведет к принудительной перезагрузке Gunicorn‘a системой, т.к. тот начнет утилизировать весь процессор:
gunicorn.service: A process of this unit has been killed by the OOM killer

То есть, для сервера с 2 ядрами, лучшая конфигурация будет такая:
gunicorn --workers 5 wsgi:app

А также, у Sync воркеров есть Gthread класс:
gunicorn --workers 5 --threads 2 wsgi:app
Указывая параметр тредов, воркеры автоматически становятся класса Gthread.

Треды помогут увеличить производительность, если количество воркеров уже не увеличить.
Такая настройка подходит для не слишком требовательных к CPU, быстрых запросов, I/O операций, SQL. В общем и целом, использование тредов помогает уменьшить утилизацию памяти Gunicorn‘ом.

Такая вот небольшая шпаргалка по оптимизации Gunicorn, надеюсь, кому-то будет полезно!