Django. Асинхронность: если выполняется длительный запрос, весь сервер висит у остальных пользователей?

Question

[KTOTAM]

Здравствуйте. Изучаю джанго, все устраивает пока дело не доходит до обработки длительных запросов (связка nginx-uwsgi-django). Получается если пользователь выполняет длительный запрос (происходит запрос к базе), весь сервер висит у остальных пользователей. Не могу понять как правильно организовать настройку сервера, на что обращать внимания (потоки, процессы). Единственный ли выход (без извращений) использовать celery везде на длительных запросах. Или использовать gunicorn (там прочитал есть асинхронность). Спасибо за помощь.

Comments

[viacheslav_ustinov]

Добрый день, в подобных ситуациях стоит еще проверить настройки гуникорн, если запускается через него.
Если все работает в докере, то по привычке в CMD может быть что-то в духе CMD ["gunicorn", "app.wsgi:application", "--bind", "0.0.0.0:8000"], в результате чего получится один синхронный тред - и длинные операции, вне зависимости от того, в транзакции они, или нет - будут вешать всю систему. В команде запуска лучше указывать несколько потоков, например, команда может выглядеть так: CMD ["gunicorn", "app.wsgi:application", "--bind", "0.0.0.0:8000", "--workers", "4", "--worker-class", "gthread", "--threads", "4" + остальные настройки, таймаут запроса например вместо стандартного в 30 секунд и т.п.]

Answer 1

[Ivan Soshnikov]

Если вопрос относится к manage.py runserver, тогда все верно.
Но это отладочный сервер, который нельзя использовать на продакшене.
Для боевого сервера есть разные варианты запуска и настройка параметров у них разная, но в общем сводится к количеству одновременно обрабатываемых запросов.
То из-за чего вы не поняли друг-друга с @sim3x - это убийство сервером слишком долгих обработчиков запроса. Как раз, чтобы не исчерпать количество воркеров, обрабатывающих запросы клиентов.
В общем гуглите на тему запуска вофнго на боевых серверах. uwsgi, gunicorn etc

Answer 2

[KTOTAM]

Как то глупо получилось. В пятницу выставил несколько воркеров, по прежнему сервер подвисал. Сегодня пришел всё работает, тоесть и пользователь ждет формирование отчета и другие могут работать с сайтом. Для надежности добавил еще пару потоков. Видимо забыл перегрузить настройки. Ответившим спасибо. Я так понимаю далее правильнее будет оборачивать длительные запросы в celery.

Comments

[Ivan Soshnikov]

Дополнительно имеет смысл ограничить количество односременных соединений для одного IP. Иначе у вас один клиент может запустить формирование толпы отчетов и остальные обломаются. А так будет обламываться только "жадный" клиент.
Плюс поставьте atop - он сохраняет данные о загрузке сервера в лог и потом этот лог можно проиграть.

[KTOTAM]

@soshnikov Спасибо за подсказки.

[Евгений]

Вы уверены что где-то не лочятся таблицы и по этой причине другие клиенты ждут?