Я создаю веб-приложение, которое будет манипулировать звуковыми файлами (пэд, микширование, объединение и т. д.), И я обнаружил, что sox делает именно то, что я хочу. Sox - это программа командной строки Linux, и я чувствую себя немного неудобно, когда веб-приложение python запускает новые процессы sox на моем сервере для каждого запроса.
Пример:
import os
os.system('sox input.wav -b 24 output.aiff rate -v -L -b 90 48k')
Мне эта установка кажется немного нестабильной.
Итак, мой вопрос: как лучше всего запускать программы командной строки из веб-приложения на Python (или на любом языке сценариев)?
Очереди сообщений - это одно, что нужно реализовать, чтобы обойти весь цикл ответа на запрос. Но есть ли другие способы сделать эти вещи более элегантными?
@ S.Lott Не совсем так, поскольку он гораздо более специфичен для контекста веб-сервера / веб-приложения.
@Томас. Я не вижу, как «паутина» что-то меняет в этом случае. Можете ли вы объяснить, почему при запуске подпроцесса важна «сеть»?
@ S.Lott OP выражает озабоченность запуском подпроцесса для каждого запроса. Таким образом, речь идет не только о запуске подпроцессов, но и, например, об ограничении их общего количества.
@ThomasH: "ограничение их общего количества"? Казалось, что запрос-ответ веб-сайта выполняется быстро, но этот подпроцесс может быть медленным. Сложно сказать. Я не понимаю, почему другие ссылки не связаны.
> Я чувствую себя немного неудобно,> имея веб-приложение python> запускать новые процессы sox на моем> сервере для каждого запроса. На мой взгляд, это означает, что он опасается, что, если он откроет свой веб-сервер для публики, он мало что сможет сделать, чтобы предотвратить потребление ресурсов своего сервера, если 15000 человек решат нажать на кнопку, которая запустит sox этим способом.






Я не знаком с sox, но вместо того, чтобы делать повторные вызовы программы в виде командной строки, можно ли настроить ее как службу и подключаться к ней для запросов? Вы можете взглянуть на интерфейс подключения, такой как sqlite, для вдохновения.
Вы на правильном пути, но, к сожалению, sox не работает как серверный демон. По крайней мере, насколько я могу судить.
Модуль subprocess - предпочтительный способ запуска других программ из Python - гораздо более гибкий и приятный в использовании, чем os.system.
import subprocess
#subprocess.check_output(['ls', '-l']) # All that is technically needed...
print(subprocess.check_output(['ls', '-l']))
подпроцесс импорта; subprocess.check_output (['ls', '-l']). для использования ls -l в командной строке. check_output () также возвращает вывод команды.
при использовании subprocess.check_call(['ls','-l']) вам не нужно распечатывать результат.
что не так с использованием os?
This whole setup seems a little unstable to me.
Поговорите с ребятами из ffmpegx о наличии внешнего интерфейса Графический интерфейс над серверной частью командной строки. Похоже, их это не беспокоит.
В самом деле, я утверждаю, что интерфейс Графический интерфейс (или веб-интерфейс) поверх серверной части командной строки на самом деле более стабилен, поскольку у вас очень и очень чистый интерфейс между Графический интерфейс и командой. Команда может развиваться с другой скоростью, чем в Интернете, если параметры командной строки совместимы, у вас нет возможности поломки.
Если вас беспокоит производительность сервера, обратите внимание на ограничение количества запущенных процессов sox. Если ограничение было достигнуто, вы всегда можете кэшировать запрос и сообщить пользователю, когда он будет завершен, любым способом, который подходит вашему приложению.
В качестве альтернативы используйте n рабочих скриптов на других машинах, которые извлекают запросы из базы данных и вызывают sox, а затем отправляют полученный выходной файл туда, где он должен быть.
Связанные: stackoverflow.com/questions/89228/…, stackoverflow.com/questions/311601/…