#node.js #garbage-collection #scalability
#node.js #сборка мусора #масштабируемость
Вопрос:
Хотя Node.js довольно горячая тема, я случайно обнаружил, что об этом сообщается Node.js может не подходить для приложения реального времени из-за его модели сборки мусора (http://amix.dk/blog/post/19577 ). И некоторые тесты показывают, что Node.js реагирует медленно по сравнению с RingoJS(http://hns.github.com/2010/09/29/benchmark2.html ).
На данный момент Node.js привязан к движку JavaScript версии 8, который использует GC, останавливающий мир поколений.
Итак, было бы Node.js сбой при большом количестве входящих запросов? Если бы была реальная производственная статистика, это было бы лучше.
Спасибо
Комментарии:
1. Если у вас достаточно подключений, чтобы GC что-то изменил, тогда вы будете запускать node как несколько процессов, масштабирующихся по вашим ядрам. Это, по крайней мере, уменьшит «ущерб» от GC.
2. Это может повысить пропускную способность, но не устраняет проблему с высокой задержкой при запуске GC.
Ответ №1:
Стоимость сборки мусора зависит от количества объектов в куче, особенно от количества долгоживущих объектов. Чем больше у вас есть, тем больше времени будет потрачено на GC.
Да, в настоящее время V8 иногда может делать значительные паузы при сборке, если куча большая. Похоже, что команда V8 работает над минимизацией стоимости каждой паузы GC за счет распространения работы. Вы можете увидеть стоимость GC в ваших собственных программах узла, запустив его с --trace-gc .
Для многих приложений стоимость GC компенсируется все более превосходным оптимизирующим компилятором. Я бы посоветовал попробовать простую программу и измерить как стоимость GC, о которой сообщается в версии 8, так и задержку между клиентами. Я обнаружил, что затраты на сборку данных практически полностью игнорируются, когда клиенты подключаются через открытый Интернет.