Масштабирование сценария ruby ​​путем запуска нескольких процессов вместо использования потоков

Question

Я хочу увеличить пропускную способность скрипта, который делает чистый ввод / вывод (скребок). Вместо того, чтобы делать его многопоточным в ruby ​​(я использую интерпретатор 1.9.1 по умолчанию), я хочу запустить несколько процессов. Итак, есть ли система для этого, где я могу отслеживать, когда кто-то заканчивает, чтобы перезапустить его снова, чтобы у меня в любое время работал номер X. Также некоторые будут работать с разными аргументами команд. Я думал о написании bash-скрипта, но это звучит как потенциально плохая идея, если уже существует метод для выполнения чего-то подобного в Linux.

Answer 1

Я бы порекомендовал не разветвляться, а вместо этого использовать EventMachine (и отличный em-http-request , если вы используете HTTP). Управление несколькими процессами может быть немного сложнее, даже больше, чем управление несколькими потоками, но, по сравнению с этим, намного проще. Поскольку вы хотите делать в основном сетевой ввод-вывод, который состоит в основном из ожидания, я думаю, что выравниваемый подход также будет масштабироваться или лучше, чем разветвление или многопоточность. И самое главное: для этого потребуется гораздо меньше кода, и он станет более читабельным.

Даже если вы решите запустить отдельные процессы для каждой задачи, EventMachine может помочь вам написать код, который управляет подпроцессами, используя, например, EventMachine.popen.

И, наконец, если вы хотите сделать это без EventMachine, прочитайте документы для IO.popen , Open3.popen и Open4.popen . Все делают более или менее одно и то же, но дают вам доступ к stdin, stdout, stderr (Open3, Open4) и pid (Open4) подпроцесса.

Answer 2

Вы можете попробовать fork http://ruby -doc.org / core / classes / Process.html # M003148

Вы можете получить PID взамен и посмотреть, запустится ли этот процесс снова или нет.

Если вы хотите управлять параллелизмом ввода-вывода. Я предлагаю вам использовать EventMachine.

Answer 3

Вы можете либо

1. внедряет (или находит эквивалентный драгоценный камень) ThreadPool (ProcessPool, в вашем случае) или
2. подготовить массив из всех, скажем, 1000 задач для обработки, разделить его, скажем, на 10 блоков по 100 задач (10 - это количество параллельных процессов, которые вы хотите запустить), и запустить 10 процессов, из которых каждый процесс сразу получает 100 заданий на обработку. Таким образом, вам не нужно запускать 1000 процессов и контролировать, чтобы не более 10 из них работали одновременно.