Ребята, правильно ли я понимаю что к примеру нагрузку 100к

рпс нода не держит и форкать кластером бесполезно?
Сколько максимум нода держит рпс?

Как понять "нода не держит"? Что под капотом принимает запросы - express/fastify/koa/иное... За чем стоит нод-сервис - напрямую или за nginx-ом... Что отдает статику - нода или все тот же nginx... и еще куча вопросов

Полагаю, что первое во что ты упрешься - это пропускная способность канала, где у тебя находится сервер. 100 тысяч запросов в секунду - это просто дохрена. Я думаю, что у VK средний показатель меньше будет.

я думаю, что ты ошибаешься, если имеешь ввиду vk в общем.

100 K не держит, а миллион держит habr.com/ru/post/123154/

Не думаю. Взять статистический день без обновлений или каких-то ивентов, учесть ночной спад и взять среднее от показателей. Ну я бы до 200 тысяч докинул, но не больше.

а есть посвежее?) друг спрашивает

Нет

Просто хело ворд. Даже у этого предел есть.

Милион запросов в секунду?нода? Без балансировщика?

И какой практический смысл этого синтетического "хелло"? К тому же опять же - на чем реализован веб-сервис?

Напрямую нода. В том и вопрос.

Смысл вопроса в том что бы понять возможности ноды.

Этот синтетический тест ничего не скажет про "возможности ноды" )))

То есть хеловорлд на ноде обслуживает бесконечное число запросов в секунду? 😂

Это значит, что сравнивать и оценивать возможности чего бы то ни было нужно с "привязкой к местности". Давайте сравним "возможности" мазератти с мтз в перепаханном поле и поиом будем возмущаться к производителю, где разгон до сотни за... да вообще где сотня!?

Канал. Понятно. Умножаем вес запроса на количество. Какое следующее узкое место?

50к на ядро

Как это? Тест покажет предел ноды

Ничего он не покажет ))) в первую очередь - какое железо, второе - какая ось и ее настройки, третье - уже говорил, какой модуль для реализации сервера...

Естественно тест будет в идеальных условиях, мы же не статью на Хабре пишем

Я не с чем не сравниваю. Я спрашиваю о поможет ли масштабирование кластером или пм2 ноде? Какой смысл добавлять ядра если мы забили запросами асинхронный канал, так сказать?

А Это если балансировка не нодой ведь?

+

Предел ноды вылезет на конкретной задаче и ее реализации в ее "однопоточности" на ядре... Если код на одном ядре будет выполняться дольше, чем приходят запросы - то и будет пределом... И это очень сильно зависит от многих факторов...

Это если делать только http запросы напрямую в ноду в кластере

Зависит от того, насколько долго в ходе запроса нода ждеть и соответственно вынуждена держать объекты в памяти

Если ты такой дотошный, вот тебе задача - получить максимальный rps

io? Он один на всю систему. А остальное решаемо увеличением

А оценку потом поставите, МарьВанна? Мне эти тесты не нужны - мне достаточно понимать архитектуру и особенности, чтобы писать сервисы с запасом на пиковые нагрузки. А если вам нужно получить некую абстрактную цифру не имеющую ничего общего с реалиями - это сами )))

Задача может требовать миллиона rps, и если такой инструмент как нода даже в синтетике не может с ней справиться, то нет смысла на ноде писать

При миллионе rps, можно нанять крутых сеньеров и переписать нормально

Проблема не в инструменте, а в человеке... даже в сите можно наносить бочку воды, если подойти с умом,

А ты статью по ссылке читал?

Мастер процесс в кластере это тоже нода. Получается простым масштабированием на ядра нельзя бесконечно пользоваться?

Некоторые инструменты даже в теории не могут решить задачу, даже если им будет пользоваться очень умный человек

Сейчас бы путать запросы и соединения

а если в кластере?

а в чем разница кластер или нет - я потому и уточнил конкретно "на одном ядре"... а дальше количество ядер увеличит возможности, балансировщик еще больше увеличит возможности... даже если простой нгинкс повесить как балансировщик, а за ним с десяток серваков 16ядерных и на каждом запустить кластер - то производительность будет "космической" по сравнению с каким-нибудь воркстейшном на одном 8-ядерном проце

Например =) ?

CheckDisk от винды.

Nodejs

Это что за зверь =) ?

Штука которая в виде проверяет целостность диска при всяких некорректных завершениях работы

Космической будет если база данных будет иметь реплики

вооот, именно, еще один человек понимает, что циферки нужно оценивать "по месту", а не абстрактно =)

По мне так логично это))

ну видишь, а некоторым этого не понять и хотят неких абстрактных "возможностей ноды"

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

А что если сессия в jwt?

если ты не понял вопрос мог бы уточнить или не отвечать. И зачем ты пишешь что мне не понять?

А вот кстати В твоём вопросе есть утверждение Оно на чём основано?

если бы я неверно понял вопрос, то вы его могли уточнить и сразу обратить на это внимание, однако продолжили дискуссию, совершенно не воспринимая мои аргументы, суть которых - нельзя определять возможности любой какой бы то ни было системы "самой в себе" не учитывая условия, в которых проводится тестирование... в вашем случае - это четко определенные параметры железа, определенные настройки ОС на этом железе, строго определенные условия взаимодействия продукта (даже вариант "принять запрос - обратиться к БД - вернуть ответ" очень сильно может вляить в зависимости от самой БД, ее настроек и расположения, от сложности запроса и объема данных) - так что вариант теста "сферического коня в вакууме" ни о чем не говорит

какое?

Их даже два: что нода не выдержит, и что кластер не поможет

Откуда ты взял БД? Вопрос был про производительность ноды

Еще вопросы?

База != СУБД, это может быть обычный словарь в памяти

это я тебе отвечал. А в изначальном вопросе меня это не интересует

А, ну тогда реквест тоже не запрос извне, а некое абстрактное обращение - типа вызова метода сервиса )))

Да я уже понял что ты больше про поговорить