nginx/gunicorn connection висит на 60 секунд

Question

Я делаю запрос HTTP POST против приложения nginx-> gunicorn-> Django. Тело ответа возвращается быстро, но запрос не заканчивается полностью еще на 60 секунд.

«Окончание полностью» Я имею в виду, что различные клиенты, которых я пробовал (Chrome, wget, приложение для Android, которое я создаю) указывают, что запрос все еще выполняется, как будто ожидая большего количества данных. Прослушивание от Wireshark Я вижу, что все данные поступают быстро, а затем через 60 секунд наконец появляется ACK FIN.

Тот же запрос POST на локальном сервере разработки (./manage.py runserver) выполняется быстро. Кроме того, он быстро запускается против стрельбы из ружья, минуя nginx. Также работает быстро в настройках Apache/mod_wsgi.

Запросы GET не имеют проблем. Даже другие запросы POST в порядке. Одна разница, о которой я знаю, заключается в том, что этот конкретный запрос возвращает 201 не 200.

Я полагаю, что это связано с заголовками Content-Length, закрытыми и связанными с подключением, но еще не знают, как все должно работать правильно ,

• Бэкэнд-сервер (gunicorn) в настоящее время закрывает соединения, это имеет смысл.
• Должен ли сервер backend включать Content-Length header, или Transfer-encoding: chunked? Или, если nginx сможет справиться без них и добавить их по мере необходимости?
• Я предполагаю, что соединение keep-alive имеет хорошие значения и не должно быть отключено в nginx.

Обновление: Установка keepalive_timeout к 0 в nginx.conf исправления моей проблемы. Но, конечно же, живого нет. Я все еще не уверен, в чем проблема. Вероятно, что-то в стеке (мое приложение Django или gunicorn) не реализует chunked transfer правильно и смущает клиентов.

Answer 1

Похоже, что ваш восходящий сервер (gunicorn) каким-то образом поддерживает соединение в этом конкретном вызове api - я не знаю, почему (в зависимости от вашего кода, я думаю), но параметр proxy_read_timeout по умолчанию в nginx равен 60 секунд, поэтому кажется, что этот ответ не получен по какой-то причине.

Я использую очень похожую установку, и я не замечаю никаких проблем в POST вообще или других запросов.

Отметьте, что return HttpResponse(status=201) причинил мне проблемы раньше - кажется, Django предпочитает явно пустое тело: return HttpResponse("", status=201) для работы. Обычно я устанавливаю что-то в теле, где я ожидаю - это может быть чем-то, на что можно обратить внимание.