Тайм-аут Gunicorn Worker в запросе Django, размещенном на облачной фабрике - PullRequest
Новая
       43

Тайм-аут Gunicorn Worker в запросе Django, размещенном на облачной фабрике

0 голосов
/ 09 июля 2020

У нас есть приложение Angular + Django, размещенное в облаке dry. Я написал несколько API, из них есть один API, который непоследовательно выходит из строя с ошибкой:

WORKER TIMEOUT (pid: 120)

Этот запрос передает много данных (~ 35 МБ) и иногда приходит ответ, а иногда запрос завершается ошибкой:

net :: ERR_CONTENT_LENGTH_MISMATCH 200 (OK)

Я искал аналогичную проблему. Я мог видеть решения, говорящие об увеличении тайм-аута в файле конфигурации Gunicorn. Но такого файла у меня нет. Мы используем файл proc с содержимым как:

web: gunicorn ApplicationName.wsgi: application

Итак, как я могу увеличить тайм-аут.

А также, Увеличил бы тайм-аут иметь какое-либо влияние на приложение.

1 Ответ

1 голос
/ 10 июля 2020

Вы можете указать параметры конфигурации для Gunicorn несколькими способами. Из документов:

  1. Переменные среды
  2. Настройки платформы
  3. Файл конфигурации
  4. GUNICORN_CMD_ARGS
  5. Командная строка

https://docs.gunicorn.org/en/latest/configure.html

Я предлагаю 3 или 5. Если у вас уже есть файл конфигурации, просто добавьте его туда. Если вы этого не сделаете, добавьте его как аргумент командной строки, который вы просто задали бы в качестве аргумента команды в вашем Procfile.

Пример: 

web: gunicorn --timeout 45 package:app

Я бы посоветовал вам избегать использования 4, GUNICORN_CMD_ARGS, потому что пакет сборки использует его для установки некоторых настроек по умолчанию, которые необходимы при запуске в Cloud Foun dry. Если вы установите это, он переопределит пакет сборки и его значение по умолчанию.

На момент написания для пакета сборки установлено следующее значение по умолчанию: 

export GUNICORN_CMD_ARGS=${GUNICORN_CMD_ARGS:-'--access-logfile -'}

https://github.com/cloudfoundry/python-buildpack/blob/master/src/python/supply/supply.go#L702

Если бы вы действительно хотели использовать эту опцию, вы могли бы. Вам просто нужно будет указать значения по умолчанию, иначе вы потеряете журнал из Gunicorn. Основной риск здесь будет заключаться в том, что пакет сборки изменит свои настройки по умолчанию в будущем. Тогда вы будете рассинхронизированы c.

В качестве примечания, вы можете также посмотреть на параметры asyn c worker. Если у вас есть код, который в основном ожидает, например, для ввода-вывода, это может быть лучший, более масштабируемый вариант (в отличие от увеличения тайм-аута).

https://docs.gunicorn.org/en/latest/design.html#choosing -a-worker- введите

Вы можете сделать это, установив пакеты для выбранного вами asyn c worker.

https://docs.gunicorn.org/en/latest/install.html#async -workers

Затем добавьте флаг --worker-class <worker> к аргументам в вашей команде запуска Procfile (или используя любой другой метод конфигурации поддержки Gunicorn). Примечание - вам не нужно включать --timeout при использовании этой опции.

https://docs.gunicorn.org/en/latest/settings.html#worker -класс

Пример: 

pip install gunicorn[eventlet]
gunicorn --worker-class eventlet package:app
...