Есть ли лучший способ обработать результаты дорогостоящего блокирующего процесса Python через HTTP?

Question

У нас есть веб-сервис, который обслуживает небольшие произвольные сегменты фиксированного инвентаря больших файлов MP3. Файлы MP3 генерируются на лету приложением python. Модель состоит в том, чтобы выполнить запрос GET к URL-адресу, указывающему, какие сегменты вы хотите, получить в ответ поток audio/mpeg. Это дорогой процесс.

Мы используем Nginx в качестве обработчика запросов переднего плана. Nginx заботится о кэшировании ответов на общие запросы.

Изначально мы пытались использовать Tornado на сервере для обработки запросов от Nginx. Как и следовало ожидать, блокирующая операция MP3 удерживала Tornado от своей работы (асинхронный ввод-вывод). Итак, мы пошли в многопоточном режиме, что решило проблему блокировки и показало хорошие результаты. Тем не менее, он ввел тонкое состояние гонки (под нагрузкой реального мира), которое мы еще не смогли диагностировать или воспроизвести. Состояние гонки искажает наш вывод MP3.

Итак, мы решили настроить наше приложение как простой обработчик WSGI за Apache / mod_wsgi (все еще с Nginx впереди). Это устраняет проблему блокировки и состояние гонки, но создает каскадную нагрузку (т. Е. Apache создает слишком много процессов) на сервере в реальных условиях. Мы работаем над настройкой Apache / mod_wsgi прямо сейчас, но все еще на стадии проб и ошибок. (Обновление: мы вернулись к Торнадо. См. Ниже.)

Наконец, вопрос: мы что-то упускаем? Есть ли лучший способ обслуживать дорогостоящие ресурсы ЦП через HTTP?

Обновление: Благодаря информированной статье Грэма, я почти уверен, что это проблема настройки Apache. Тем временем мы вернулись к использованию Tornado и пытаемся решить проблему повреждения данных.

Для тех, кто так быстро бросил железо в эту проблему, Tornado и немного многопоточности (несмотря на проблему целостности данных, вызванную многопоточностью) приемлемо справляются с нагрузкой на небольшом (одноядерном) экземпляре Amazon EC2.

Answer 1

Вы пробовали Нерест ? Это сервер WSGI с гибким ассортиментом режимов потоков.

Answer 2

Пожалуйста, определите «каскадную нагрузку», так как она не имеет общего значения.

Ваша наиболее вероятная проблема будет, если вы запускаете слишком много процессов Apache.

Для такой нагрузки убедитесь, что вы используете prefork mpm, и убедитесь, что вы ограничиваете себя соответствующим количеством процессов (не менее одного на процессор, не более двух).

Answer 3

Вы совершаете ошибку, используя встроенный режим Apache / mod_wsgi? Читайте:

http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html

Убедитесь, что вы используете режим демона, если используете Apache / mod_wsgi.

Answer 4

Вы можете рассмотреть систему очередей с методами уведомления AJAX.

Всякий раз, когда есть запрос на ваш дорогой ресурс, и этот ресурс необходимо сгенерировать, добавьте этот запрос в очередь (если его еще нет). Эта операция очереди должна возвращать идентификатор объекта, к которому вы можете обратиться, чтобы получить его статус.

Далее вам нужно написать фоновый сервис, который раскручивает рабочие потоки. Эти работники просто снимают запрос с запроса, генерируют данные и затем сохраняют местоположение данных в объекте запроса.

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

Так работают БОЛЬШИЕ медиа-сайты, особенно те, которые имеют дело с видео. Однако, это может быть излишним для вашей работы с MP3.

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

Answer 5

Похоже, вы все делаете правильно - просто не хватает мощности процессора: можете ли вы определить, какова нагрузка на процессор в процессе генерации этих MP3?

Я думаю, что следующее, что вам нужно сделать, это добавить больше оборудования для рендеринга MP3 на других машинах. Или это, или найдите способ доставить предварительно отрендеренный MP3 (может быть, вы можете использовать некоторые из ваших носителей?)

Кстати, масштабирование для Интернета было темой основной лекции Джейкоба Каплана-Мосса на PyCon Brasil в этом году, и это далеко не закрытая проблема. Стек технологий, с которыми нужно работать, впечатляет - (хотя я не смог найти онлайн копию презентации, - извините за это)