2016-09-15 3 views
0

Является ли это веб-сервером, не создающим/контролирующим поток (процесс), который вызывает обработчик запросов? Или есть какая-либо асинхронная/многопоточная архитектура в самом Django? Проблема в том, что когда запрос (ajax) обрабатывается в течение длительного времени, и во время этого повторного отправки этого клиента предыдущий обработчик заканчивается. Я хотел бы иметь некоторый контроль над этим: например. выполните некоторые действия по очистке. Или в некоторых случаях прекратите обработчик вручную.Управление потоком обработчика Django

ответ

1

Django - это не веб-сервер, это веб-фреймворк, так как вы сказали, что он порождает потоки для обработки входящих запросов, но это задача веб-сервера, чтобы принять и, наконец, ответить на [http (s)] запросы пользователей.

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

Кроме того, чтобы получить Django для работы, вам нужен разъем, который понимает WSGI, для этого люди используют в основном любит из gunicorn, uwsgi, mod_wsgi и так далее. Вам также нужно настроить их для принятия более длинных значений для тайм-аута.

Например, если вы используете Nginx/Gunicorn, вы можете обратиться к this question, чтобы узнать, как вы собираетесь устанавливать таймауты.

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

В вашем случае, если это не огромное вычисление, вы можете просто увеличить значение таймаута. Но если ваши вычисления могут занять много времени, скажем, 45+ секунд, лучше изменить способ выполнения действий и реализовать решение с использованием сельдерея и фоновой обработки запросов.

Редактировать.

Если вы хотите знать, кто именно обрабатывает темы и что происходит за кулисами, я рекомендую вам прочитать this posting о Gunicorn, так как это хорошее представление о том, как все работает. Также хорошо читать на самом design page of Gunicorn, прежде чем читать это. В принципе, как WSGI-программа, так и WebServer будут убивать поток в случае тайм-аута.

Если ваш тайм-аут django истекает раньше (время отпусков), программа WSGI убивает поток. Если, с другой стороны, тайм-аут увольнителя установлен выше, чем у Nginx, Nginx убьет нить.

+0

Спасибо за разъяснение. Мой поиск данных длинный, и я нахожусь на пути к использованию Сельдерея. Но мне все еще интересно. ВОЗ из двух отвечает за убийство нитки? (Я вижу, когда получен дубликат запроса, в то время как предыдущий вычисляется). Могу ли я законным образом влиять на это поведение иначе, чем изменять тайм-аут сервера, или я могу принудительно прекратить прерывание потока, когда захочу? – VladimirLenin

+1

@VladimirLenin Обновлен мой ответ. – SpiXel

Смежные вопросы