Потоки vs процессы на примере нативного Node.js аддона для нагрузочного тестирования

Дело в том, что сам по себе socket.io обещал давать неплохие результаты при использовании тысяч различных постоянных соединений.
В основном, речь идет о клиентах как браузеров. Но, как я понимаю, ваша проблема проявлялась в виде блокировок event-loop в процессе сервера.
Ну, и не даром в minimum-rpc используют socket.io вместо, например, стандартных http или process.send().

Интересно было бы посмотреть на сравнительные результаты.

Возможно, также проблема решения со 100 процессами и process.send() могла заключаться в том, что каждый процесс выполнял слишком мало задач и сразу завершался. Из статьи неизвестно, как организован пулл процессов. Вы запускали 100 процессов и потом раздавали им задачи, или Вы организовывали пулл, который запускает 100 одновременных процессов, и каждый процесс выполнял одну или несколько задач и завершался, а на месте завершенного процесса пуллом запускался новый?

По моему скромному мнению, второй способ предпочтительнее, более защищен от утечек, защищен от различных необработанных исключений. Но тут надо понимать, что каждый новый процесс кушает при запуске довольно много CPU-time, и нужно соблюдать пропорцию, хотя бы:
Runtime_CPU_time * Proc_count < Execute_CPU_time, где:

• Runtime_CPU_time — это количество затраченного CPU-time для запуска процесса;
• Execute_CPU_time — это сумма затраченного CPU-time для выполнения всех задач порученных одному процессу;
• Proc_count — количество одновременно запущенных процессов.

Если проблема 100 процессов заключалась в I/O, то тут необходимы испытания на разных версиях ядер ОС. Пробовали ли Вы запускать тесты на FreeBSD? Сомневаюсь, что проблема производительности process.send() упирается в I/O. Всегда есть вариант разгрузить количество (частоту) использования process.send() и объем информации, передаваемой через process.send(), в пользу самостоятельной загрузки данных процессом и последующим самостоятельным сохранением результатов.

Сколько раз сам использовал process.send(), с Вашими трудностями я не сталкивался. Правда, в последний раз это было давно, так я использовал для запуска тех скриптов NodeJS версий 0.6.x (если мне не изменяет память).

Как-то, в свое время, мне необходимо было написать парсер VK для расчетов различных статистических данных. На самом деле, действие происходило чуть позднее новости о том, что Яндекс стал индексировать VK. Необходимо было использовать максимум доступных ресурсов для обработки максимального объема информации за ограниченное время. На тот момент, располагали тремя арендованными в ЦОД серверами с различными характеристиками.

Я использовал комбинированный подход, то есть, master-процесс запускал несколько worker-процессов, каждый из которых выполнял задачи в несколько потоков. Причем, для использования максимума свободных ресурсов, master-процесс в процессе выполнения руководил количеством одновременно запущенных процессов и количеством потоков в каждом worker-процессе. Master-процесс различал несколько состояний ОС: если весь chain процессов превышал общий Memory_limit, master-процесс уменьшал количество процессов и увеличивал количество потоков; если worker-процессы превышали CPU_limit, он увеличивал количество процессов и уменьшал количество потоков в каждом процессе. Также master-процесс останавливал перегруженные и idle процессы.

Для реализации использовал простые инструменты:

• для запуска worker-процессов использовал child_process.spawn() (позднее появился Cluster);
• для передачи данных между процессами использовал process.send();
• для выполнения задач в несколько потоков использовал async.queue() модуля async.

Возможно, последние версии NodeJS перегружены функционалом. В те времена V8 умел использовать только 32-битную архитектуру ОС. Опять же, если мне не изменяет память, свеже-запущенный процесс node занимал 1.8Мб оперативной памяти, а процесс с запущенным парсером html-страниц занимал памяти около 15Мб и точно не более 32Мб (был индивидуальный heap-лимит, превышая который, процесс считался зависшим и перезапускался).