Как мне справиться с блокировкой ввода-вывода в mod_wsgi / django? - PullRequest
Новая
       0

Как мне справиться с блокировкой ввода-вывода в mod_wsgi / django?

4 голосов
/ 24 августа 2010

Я запускаю Django под Apache + mod_wsgi в режиме демона со следующей конфигурацией: 

WSGIDaemonProcess myserver processes=2 threads=15

Мое приложение выполняет некоторые операции ввода-вывода в бэкэнде, что может занять несколько секунд.

def my_django_view:
    content=... # Do some processing on backend file
    return HttpResponse(content)

Похоже, что если я обрабатываю более 2 http-запросов, обрабатывающих этот тип ввода-вывода, Django просто заблокирует, пока не завершится один из предыдущих запросов.

Ожидается ли этоповедение?Разве многопоточность не может помочь облегчить это, то есть я не должен быть в состоянии обработать до 15 отдельных запросов для данного процесса WSGI, прежде чем я увижу такой вид ожидания?

Или я что-то здесь упускаю?

Ответы [ 3 ]

2 голосов
/ 24 августа 2010

+ 1 к ответу Радомира Доперальского.

Если задача занимает много времени, вы должны делегировать ее процессу, находящемуся вне цикла запрос-ответ, с помощью стандартного cron или некоторой распределенной очереди задач, такой как Celery

2 голосов
/ 24 августа 2010

Если обработка выполняется в python, то Global Interpreter Lock не освобождается - в одном процессе python одновременно может выполняться только один поток кода python.GIL, как правило, выпускается внутри кода C - как, например, большинство операций ввода-вывода.

Если этот вид обработки будет происходить много раз, вы можете рассмотреть запуск второго «рабочего» приложения какДеймон, чтение задач из базы данных, выполнение операций и запись результатов обратно в базу данных.Apache может решить убить процессы, которые слишком долго отвечают.

0 голосов
/ 16 ноября 2016

Базы данных для разгрузки рабочих нагрузок были достаточно популярны в 2010 году, и тогда это была хорошая идея, но мы продвинулись немного дальше.

Мы используем Apache Kafka в качестве очереди для хранения рабочей нагрузки в полете.Итак, Dataflow теперь:

Пользователь -> Apache httpd -> Kafka -> процессор демона python

Пользовательская операция поста помещает данные в систему для обработки через приложение wsgi, которое просто очень быстро записывает ихв очередь Кафки.Минимальная проверка работоспособности выполняется в почтовой операции, чтобы сохранить ее быстротой, но обнаруживает некоторые очевидные проблемы.Kafka хранит данные очень быстро, поэтому http-ответ zippy.

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

Это позволяет очень и очень быстро выполнить обработку;оптимальное использование ресурсов, поскольку у нас есть другие автономные блоки, которые обрабатывают pull-from-kafka и могут настроить его для уменьшения задержки по мере необходимости.Kafka - это HA с одними и теми же данными, записанными в несколько блоков в кластере, поэтому мой менеджер не жалуется на сценарии «что произойдет, если».

Мы довольно довольны Kafka.http://kafka.apache.org

...