Worker_threads vs Queues для задач с интенсивным использованием процессора

Question

Я думаю о реализации видеопреобразователя с использованием node.js с ffmpeg, но, поскольку это трудоемкая задача процессора, он может заблокировать express от обработки других запросов. Я нашел пару статей об этом, и некоторые из них используют рабочие потоки, в то время как другие используют очереди, такие как Agenda js или Bull.

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

Answer 1

Здесь две подзадачи:

1. Первая проблема заключается в том, чтобы ваш интерфейс реагировал во время преобразования. Если преобразование может занять много времени, и у вас нет хорошего способа разбить его на небольшие куски (например, чтобы обрабатывать запросы между ними), то вам действительно нужно будет обрабатывать его асинхронно, действительно.

   Так вы, вероятно, захотите создать хотя бы один рабочий поток для параллельной работы с основным потоком.

2. Вторая проблема - по-видимому, - сделать преобразование быстрым. Поскольку - как вы пишете - это задача, интенсивно использующая процессор, она может получить выгоду от дополнительных рабочих потоков. Это может означать:

   2a. несколько потоков, работающих над одной задачей преобразования (в очереди), одновременно

   2b. несколько потоков, каждый из которых работает над отдельными задачами преобразования одновременно

   2 c. сочетание обоих.

Хорошая новость заключается в том, что вам действительно не придется беспокоиться о большей части этого самостоятельно, потому что a) ffmpeg уже использует многопоточность, где это возможно ( это зависит от используемого кода c! ), предоставляя вам готовое решение для 2a. И б), node-fluent-ffmpeg (или node-ffmpeg) уже предназначен для асинхронного вызова ffmpeg, решая, таким образом, задачу 1.

Единственный оставшийся вопрос - вы хотите убедиться, что запускать только одно задание ffmpeg за раз (в очереди) или запускать преобразования, как только они запрашиваются (2b / 2 c)? Последнее будет легче реализовать. Однако , это может привести к неприятностям, если одновременно выполняется много заданий. По крайней мере, каждое задание преобразования будет буферизовывать некоторые входные и некоторые выходные данные, и это может привести к проблемам с памятью,

. Здесь на экране появляется очередь. Вы захотите поместить задания в простую очередь и запустить их так, чтобы одновременно выполнялось не более n . Оптимальный n не обязательно будет 1, но вряд ли будет больше 4 или около того (опять же, поскольку каждое отдельное преобразование использует параллелизм). Вам придется немного поэкспериментировать с этим, помня, что ответ может отличаться от кода c до кода c.