Назад | Перейти на главную страницу

nginx, gunicorn и django weird 504 gateway timeout

У меня есть установка nginx / gunicorn / django следующим образом:

Nginx

server {
    listen 80;
    server_name myserver.com;

    root /www/python/apps/pyapp/;

    access_log /var/log/nginx/myserver.com.access.log;
    error_log /var/log/nginx/myserver.com.error.log;


    location / {
        proxy_pass_header Server;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Scheme $scheme;
        proxy_connect_timeout 10;
        proxy_read_timeout 10;
        proxy_pass http://localhost:8081/;
    }
}

Мой сценарий выскочки для Gunicorn

description "pyapp"
start on [2345]
stop on [06]

respawn

# start from virtualenv path
chdir /www/python/apps/pyapp/
exec /usr/bin/gunicorn  -w 11 -b 0.0.0.0:8081 --error-logfile=/var/log/nginx/pyapp.log wsgi:application

Сервер работает нормально, на запросы хорошо отвечают. Однако, когда я начинаю направлять трафик на эту настройку со своего старого сервера, страницы начинают выдавать 504 ошибки тайм-аута шлюза.

То, что делают запросы, - это только выборка данных из БД и рендеринг с использованием django-rest-framework. Глядя на список процессов MySQL, кажется, что там нет застрявших запросов. Это как-то странно.

Есть рекомендации?

Сначала вы можете попробовать, как ваш бэкэнд (django / gunicorn) работает без nginx впереди. ab (тест apache) - простой инструмент для этой задачи.

Вы можете запустить его прямо с сервера или если ваш порт 8081 не защищен брандмауэром ни с одной машины:

ab -c 50 -n 500 http://localhost/path-xyz/

(ab доступен в пакете apache2-utils, по крайней мере, в системах на основе Debian) -c означает «параллелизм», -n - количество запросов.

Если бэкэнд является узким местом, и вы все равно используете nginx - это может быть вариант для некоторого кеширования (не знаю ваше приложение, но, возможно ...). Если ваш API предоставляет данные, которые часто меняются, вы можете установить очень короткое время кеширования. (От 1 до 10 секунд) - поэтому, если у вас, например, 100 запросов в секунду, только один из них должен попасть в бэкэнд, остальные получат кешированный ответ.

Для прокси / кеша nginx см., Например, Вот.