Итак для истории:
Особой разницы, с точки зрения производительности, при использовании балансера Nginx против NodeJS нет.
Мы сравнивали нашу старую архитектуру построенную с использованием
strong-cluster-control c балансировкой через NodeJS, и новую на основе
luster с балансировкой на Nginx.
В обоих случаях был поднят кластер на cpu-1 процессов (в данном случае 32-1)
В случае luster каждый процесс слушает свой unix сокет, балансировка внутри ноды отключена. В Nginx создан апстрим на эти самые 31 сокет с балансировкой least_connect.
luster был использован как готового решение, поддерживающее сохранение индекса воркера при его перезапуске, в основных тестах другие его возможности не использовались.
В стрельбах с постоянной нагрузкой на реальном проекте были замечены незначительные отклонения потребления system и user CPU как в одну так и в другую сторону.
В стрельбах на отказ стабильность повысилась на 5-10%.
Тестируемое приложение является stateless middleware с преимущественно асинхронными операциями, период простоя в одном стеке не больше 5 мс. Приложение на данный момент не занимается рендерингом шаблонов.
Для приложений с тяжелыми синхронными операциями (с периодом простоя в стеке больше 50мс) был получен совет использовать следующую архитектуру:
Все так же поднимаем кластер на cpu-1, но настраиваем luster на меньшее количество групп, например по 4 воркера в каждой группе, т.е. 4 воркера будут слушать один сокет.
Балансировку в ноде все так же отключаем. Получаем предварительную балансировку least_connect средствами Nginx и дополнительную балансировку средствами системы, которая будет делать выбор опираясь на готовность процесса к чтению из сокета.
Простой
