Должен ли каждый веб-сайт быть собственным процессом `node.js`

Question

Мы размещаем около 150 сайтов (возможно, масштабирующихся до 300+), которые мы планируем перевести на node.js. Большинство сайтов имеют довольно низкий трафик < 1mil просмотров страниц в месяц.

Должен ли каждый веб-сайт быть собственным процессом node.js, или мы должны обслуживать все веб-сайты, используя тот же процесс node.js (или небольшой набор процессов с балансировкой нагрузки). Существует ли технический предел или разумный предел числа процессов узлов на сервере?

Процесс на сайте: Чувства неэффективны, но я не знаю, действительно ли это неэффективно. Обеспечит, чтобы один багги-сайт не влиял на другие сайты.

Процесс на ядро ​​/ небольшой набор процессов: Вероятно более высокая производительность, но что происходит, когда мне нужно обновлять кодовую базу сайтов, не будут ли они удалены по другим сайтам? Кроме того, ошибки кода на одном сайте влияют на другие сайты.

В идеале, я бы предпочел один процесс на сайт, чтобы мы могли размещать все сайты с каждого рабочего сервера. Таким образом, при увеличении нагрузки мы можем просто развернуть еще один идентичный рабочий сервер и сбалансировать нагрузку между ними без необходимости произвольно сказать, что SiteA переходит на ServerA, а SiteB переходит на ServerB. Любые node.js гуру доступны, чтобы предложить некоторую мудрость?

Все статические запросы на файлы будут обрабатываться, вероятно, Nginx или что-то вроде Varnish.

Answer 1

Здесь есть много проблем. Ответ на большую картинку заключается в том, что это зависит ... как это всегда бывает, когда вы привносите в дискуссию «производительность». При этом самый простой способ создать надежный узел - это отметить следующие основные факты о NodeJS, и я также буду комментировать их последствия, поскольку они относятся к вашим вопросам.

• Параллельность, которую вы получаете с узлом, действительно хороша в определенных ситуациях, а именно в тяжелых операциях ввода-вывода. То, о чем мы сейчас говорим, сводит к минимуму время простоя, ожидая следующего запроса. Из-за этого Node работает очень хорошо в среде, где на машине есть один процесс на ядро. Узел действительно хорошо работает, чтобы максимизировать количество доступных ЦПУ для обслуживания запросов при большой нагрузке. При этом, если у вас есть буквально другая работа ZERO в вашем четном цикле, вы можете увидеть незначительное увеличение производительности (с точки зрения максимального количества запросов/второго/процессорного ядра) за счет наличия нескольких процессов узла на ядро. Но я никогда не видел никакой выгоды от увеличения этого числа в прошлом. Даже в условиях, когда весь цикл событий был буквально просто файловым сервером.

• О процессе на комментарий сайта. Это плохая идея по многим причинам. Во-первых, удаленный узел узла может обрабатывать тысячи запросов в секунду. Наши серверы с названиями компаний опущены, размещенные через Amazon EC2 на средних кластерах (много баранов, часы центрального процессора, 4 ядра), как правило, не работают около 3000 запросов в секунду на кластер. Наши серверы выполняют честную работу процессора, для простых файловых серверов я уверен, что вы можете сделать гораздо лучше. Строго говоря, конечно, для каждого сайта вы сможете подавать больше запросов, быстро запуская каждый сайт в своем собственном процессе/ядре/эскалации! Но это не обязательно из-за дорогостоящего и сложного понимания вашей архитектуры. Я бы рекомендовал, инвестирует в установку с большим количеством оперативной памяти. Возможность кэширования часто запрашиваемых вами файлов будет приводить к тому, что ваша производительность будет бесконечно больше, чем запуск большого количества процессов для данной машины.

• В целом ОЗУ. Количество процессов, которые вы хотите запустить для данного ядра, зависит от двух факторов. Во-первых, сколько синхронной работы сделано в вашем цикле событий.Чем больше синхронной работы, тем больше времени между данным запросом и контуром события будет готово к отправке следующего. Если у вас цикл занятости, вы окажетесь в ситуации, когда вам требуется больше процессов/CPU Core. Другое, что может повлиять на это, особенно актуально для файловых серверов, - это объем оперативной памяти. Узел работает намного лучше в среде с высоким помехоустойчивостью, но вы можете сказать это о ЛЮБОМ файловом сервере на самом деле ... Что это связано с этим, это число активных асинхронных операций. Один недостаток того, как работает узел, находится под большими нагрузками, вы можете сразу получить большое количество обработчиков событий. Это отлично подходит для параллелизма/простоты, однако, если ваш сервер занят ожиданием многого асинхронного диска/ввода-вывода, он будет замедляться и крутиться намного раньше, чем если бы у вас было много ОЗУ. Если у вас недостаточно ОЗУ для обработки всех этих обработчиков событий, вы захотите придерживаться 1 процесса/ядра. В противном случае Узел может ускорить работу многих обработчиков событий и снова привести к сбою раньше, чем в противном случае.

У меня действительно недостаточно информации, чтобы рассказать вам, что вам следует делать. Это полностью зависит от архитектуры вашего конкретного сервера, сайтов, размера ваших сайтов, количества данных ... и т. Д. Но эти три уровня знаний - это основные вещи, которые помогут вам максимально использовать ваш сервер узлов. Честно говоря, ваша идея о балансировке нагрузки, смешанная с вышеприведенными соображениями, должна хорошо для вас. Разумеется, возможны микрооптимизации, но если вы это делаете, вы должны легко видеть запросы/секунды в тысячах, прежде чем вы начнете испытывать сбои из-за условий типа DDOS.

Answer 2

Нет, не делайте этого. Будь проще! И проверьте номер http://12factor.net/.

Несколько сотен процессов - это ничто по сравнению с простотой, которую вы в противном случае теряете. Было бы страшным решением на стольких уровнях иметь более одного сайта (или «логического блока приложений»), обслуживаемого одним процессом Node.

Если вы задаете этот вопрос, вам может понадобиться изучить узел еще до того, как вы перейдете на узел. Обработка ошибок и разделение проблем более сложны в узле, чем в других ситуациях. В частности, ни API domain, ни cluster не являются зрелыми. Но на самом деле это философия чистого и простого развертывания приложений, которое вы бы нарушили. Я мог бы продолжать и продолжать.