Django Nginx Gunicorn Upstream Преждевременное закрытие соединения при чтении ответа - PullRequest
Новая
       29

Django Nginx Gunicorn Upstream Преждевременное закрытие соединения при чтении ответа

0 голосов
/ 07 мая 2020

nginx conf 

server { 
    listen 80;
    server_name private.com;
    client_max_body_size 4G;
    client_body_buffer_size 8000M;
    client_body_timeout 120;
    proxy_connect_timeout 900s;
    proxy_read_timeout 900s;
    location = /favicon.ico { access_log off; log_not_found off; }
    autoindex on;

    location / {
        include proxy_params;
        proxy_pass http://unix:/home/dm/stat.cok;
    }
}

gunicorn.service 

[Unit]
Description=gunicorn daemon
After=network.target


[Service]
User=Pa
Group=www-data
WorkingDirectory=/home/un/foldername
ExecStart=/home/un/foldername/bin/gunicorn \
        --access-logfile - \
        --workers 3 \
        --timeout 450 \
        --bind unix:/home/dm/stat.sock scistat.wsgi:application

[Install]
WantedBy=multi-user.target

Я загружаю большой файл excel размером 90 МБ, он содержит 450000+ строк и 6 столбцов. После загрузки файла он вычисляет строку и столбецf файла Excel и умножает его, чтобы вычислить общую строку и столбец файла Excel, но эта ошибка показывает «преждевременно закрытое соединение в восходящем направлении при чтении заголовка ответа из восходящего потока»

1 Ответ

0 голосов
/ 07 мая 2020

Это похоже на длительный синхронный запрос - пользователь загружает большой файл, он обрабатывается в представлении, что занимает значительное время и только после того, как ответ на запрос пользователя отправлен обратно.

При обработке файла, на который нет ответа пользователю, рабочий-пулемет убит из-за тайм-аута. Чтобы убедиться в этом, попробуйте увеличить таймаут в Gunicorn до 900 или выше (затем, если он может быть прерван превышением nginx proxy_read_timeout).

Лучше не увеличивать таймаут далеко от значения по умолчанию 30 секунд (если это действительно не требуется) - попробуйте удалить / уменьшить время ожидания и изменить код, как показано ниже.

Оставьте только сохранение файла / basi c журнал проверки c в режиме загрузки - возвращать ответ как можно быстрее после того, как файл был загружен на сервер.

Используйте Celery для выполнения длительных задач / periodi c / asyn c в отдельных работниках сельдерея - например, при обработке / вычислении загруженного файла.

Можно создать отдельные конечные точки / представления для получения информации о состоянии загруженного файла или результатов.

Время обработки просмотра должно быть таким как можно меньше - это сильно влияет на пользовательский опыт. Если после запроса пользователю нужно ждать ответа дольше нескольких секунд - это нехорошо. Если это займет минуты - удачи. Длительные операции лучше выполнять асинхронно c - и

...