Существует ли лучший способ служить результатам дорогого, блокирующегося процесса Python по HTTP?
У нас есть веб-сервис, который служит маленьким, произвольным сегментам фиксированных материально-технических ресурсов больших файлов MP3. Файлы MP3 сгенерированы на лету приложением Python. Модель, выполните ПОЛУЧИТЬ запрос к URL, указывающему, какие сегменты Вы хотите, получаете audio/mpeg передайте потоком в ответ. Это - дорогой процесс.
Мы используем Nginx в качестве обработчика запросов фронтенда. Nginx заботится о кэширующихся ответах для общих запросов.
Мы первоначально пытались использовать Торнадо на бэкенде для обрабатывания запросов от Nginx. Как Вы ожидали бы, блокирующаяся операция MP3 помешала Торнадо делать свою вещь (асинхронный ввод-вывод). Так, мы пошли многопоточные, который решил блокирующуюся проблему и работал вполне хорошо. Однако это представило тонкое состояние состязания (при загрузке реального мира), что мы не смогли диагностировать или воспроизвести все же. Состояние состязания повреждает наш вывод MP3.
Таким образом, мы решили настроить наше приложение как простой обработчик WSGI позади Apache/mod_wsgi (все еще w/Nginx впереди). Это устраняет блокирующуюся проблему и состояние состязания, но создает каскадную загрузку (т.е. Apache создает слишком много процессов) на сервере при условиях реального мира. Мы работаем над настройкой Apache/mod_wsgi прямо сейчас, но все еще в эмпирической фазе. (Обновление: мы переключились назад на Торнадо. Посмотрите ниже.)
Наконец, вопрос: мы пропускаем что-нибудь? Существует ли лучший способ служить дорогим ЦП ресурсам по HTTP?
Обновление: Благодаря информированной статье Graham я вполне уверен, это - настраивающая проблема Apache. Тем временем мы вернулись к использованию Торнадо и пытаемся решить вопрос повреждения данных.
Для тех то, кто был так быстр для броска большего количества железа в проблему, Торнадо и немного многопоточности (несмотря на проблему целостности данных, представленную путем поточной обработки), обрабатывает нагрузку приемлемо на маленький (одноядерный) экземпляр Amazon EC2.
5 ответов
Вы делаете ошибку, используя встроенный режим Apache / mod_wsgi? Прочтите:
http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html
Убедитесь, что вы используете режим демона при использовании Apache / mod_wsgi.
Вы пробовали Создание ? Это сервер WSGI с гибким набором режимов потоковой передачи.
Вы можете подумать о системе очередей с методами уведомления AJAX.
Когда есть запрос на ваш дорогой ресурс, и этот ресурс необходимо сгенерировать, добавьте этот запрос в очередь (если его там еще нет). Эта операция организации очереди должна возвращать идентификатор объекта, который вы можете запросить, чтобы узнать его статус.
Затем вам нужно написать фоновую службу, которая запускает рабочие потоки. Эти рабочие просто удаляют запрос, генерируют данные, а затем сохраняют местоположение данных в объекте запроса.
Веб-страница может делать AJAX-вызовы на ваш сервер, чтобы узнать о ходе генерации и дать ссылку на файл один раз. он доступен.
Так работают БОЛЬШИЕ медиа-сайты - в частности, те, которые имеют дело с видео. Однако это может быть излишним для вашей работы с MP3.
В качестве альтернативы рассмотрите возможность запуска пары компьютеров для распределения нагрузки. Ваши потоки на Apache по-прежнему будут блокироваться, но, по крайней мере, вы не будете потреблять ресурсы на веб-сервере.
Похоже, вы что-то делаете правильно - просто не хватает мощности процессора: Можете ли вы определить, какова загрузка процессора в процессе создания этих MP3?
Я думаю, что следующее, что вам нужно сделать, это добавить дополнительное оборудование для рендеринга MP3 на других машинах. Или это, или найти способ доставить предварительно обработанный MP3 (может быть, вы сможете передать некоторые из ваших медиа?)
Кстати, масштабирование для Интернета было темой лекции Keynote Джейкоба Каплан-Мосса на PyCon Brasil в этом году, и это далеко не закрытая проблема. Стек технологий, с которыми нужно работать, впечатляет (хотя я не смог найти онлайн-копию презентации - извините за это)
Масштабирование для Интернета было темой ключевой лекции Джейкоба Каплан-Мосса на PyCon Brasil в этом году, и это далеко не закрытая проблема. Стек технологий, с которыми нужно работать, впечатляет - (хотя я не смог найти онлайн-копию презентации - извините за это) Масштабирование для Интернета было темой ключевой лекции Джейкоба Каплан-Мосса на PyCon Brasil в этом году, и это далеко не закрытая проблема. Стек технологий, с которыми нужно работать, впечатляет - (хотя я не смог найти онлайн-копию презентации - извините за это)Пожалуйста, определите "каскадную загрузку", так как она не имеет общего значения.
Ваша наиболее вероятная проблема будет, если вы запустили слишком много процессов Apache.
Для такой загрузки убедитесь, что вы используете предобработчик mpm, и убедитесь, что вы ограничиваете себя подходящим количеством процессов (не менее одного на процессор, не более двух).
.