Сокет же не тронет карту

Просто я не уверен, что нода справляется с 30000 сообщений, среди которых есть сообщения размером 2 метра

нода как раз создана для того чтобы очень эффективно работать с большими стримами в i/o, это ее ключевая фича

Если только они ипс через внешний интерфейс не гоняли

IPC сейчас гоняется через юникс сокеты

Энивей, у меня просто шина 17, сокет - 1.3

Я сам лично видел

IPC сейчас гоняется через юникс сокеты

процесс с процессом через юникссокет говорит?

Да

Редис говорят не справился с этой задачей

Редис говорят не справился с этой задачей

ну а что они гоняют между собой? нет ли там оверхеда дикого? легко там это устроить

Есть мастер процессы, в которые прилетают события назначенные определённому пользователю, далее мастер процесс находит воркер, к которому подключён юзер и передаёт в него через IPC предназначенное сообщение, и далее этот воркер отправляет это сообщение

Стоп. А там не 200 процессов на сервер?

Нет, серверов овер дофига

Нет, серверов овер дофига

ну вот надо смотреть карту коммуникаций и strace делать на воркерах

Проблема начинается, тогда когда событий слишком много

Проблема начинается, тогда когда событий слишком много

сколько?

Раза в три увеличивается - у меня сейчас нет точных цифр, но ребята говорят были проблемы когда новый сервис запускали

Кто может что-нибудь сказать по поводу https://github.com/RuntimeTools/appmetrics?

А вот такой штукой не проще ли?

Типо CPU уходил в 100% на сервере

Раза в три увеличивается - у меня сейчас нет точных цифр, но ребята говорят были проблемы когда новый сервис запускали

ну порядок хотя бы

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

Если бы был простой бродкаст, то проблем бы не было

Кстати, с каждым днём прихожу к выводу, что протокол GraphQL очень даже хорошо, и всё что сейчас городят проекты такое уг

Один батч запрос через GraphQL и всё бы нужные данные быстренько прилетели, правда это бы не решило проблемы с ивентами для определённых юзеров

GraphQL здесь не при чем

Кстати, с каждым днём прихожу к выводу, что протокол GraphQL очень даже хорошо, и всё что сейчас городят проекты такое уг

в теории все всегда прекрасно

GraphQL здесь не при чем

Это так, отступление

Если бы был простой бродкаст, то проблем бы не было

strace, ftrace, и профилирование и тогда будет понятнее, уверен там проблема в архитектуре

Возможно, я с этой архитектурой знаком только дня два)

Так вот, нужно спроектировать, чтобы система могла обработать до 2 млн пакетов в секунду

а откуда это цифра? это про tcp?

Ну я вижу сколько сейчас в пик приходится, сколько CPU на данный момент и прикидываю, что происходит, когда CPU 100%

Ну я вижу сколько сейчас в пик приходится, сколько CPU на данный момент и прикидываю, что происходит, когда CPU 100%

то есть 2 млн пакетов это с потолка? это чудовищная нагрузка если что

Да, но ведь в пиковой нагрузке приходится 1 мнл пакетов

для понимания где в ноде тонкие места и когда эвентлуп начинает сдавать

https://githubengineering.com/brubeck/

Это на все сервера

https://githubengineering.com/brubeck/

Спасибо 👍

и это про udp, про tcp иначе может быть

Спасибо 👍

там подробно где во что нода упирается

сложно представить что вы по прессингу пакетами обогнали гитхаб

Да, но ведь в пиковой нагрузке приходится 1 мнл пакетов

ты как считал что миллион? есть мониторинг какой-то?

Да, графана

Я посчитал кол - во серверов * кол-во пакетов на сервер

Да, графана

какова их структура? если это бинарные данные от пользователя это одно, если это сообщения в websockets это совсем другое

Это только сообщения websocket

Это только сообщения websocket

1 млн в секунду?! 😧

Да

а клиентов в пике сколько?

Этой статистики у меня нету

А есть

Да

соединений от клиентов сколько?

Ща графана загрузит данные

Не могу сказать сервер с этой аналитикой не отвечает

Ща графана загрузит данные

ну надеюсь что у вас сотни тысяч активных коннектов на такой объем

Да, естественно

Просто мы очень много данных гоняем

Сейчас нагрузка маленькая около 60000 пакетов в секунду

Да, естественно

а что это за проект если не секрет? он же публичный наверняка

Финансовый

Просто мы очень много данных гоняем

вот странно что у вас не прорисована карта потоков данных

Финансовый

клиенты - это реальные люди? или боты?

Я не знаю что это, но может она есть

Реальные люди

Я не знаю что это, но может она есть

ну блок-схема компонентов какая-то, кто как с кем общается, без этого вообще сложно понимать что происходит внутри

Это всё есть ofc

Я же тоже не могу всё рассказать)

Всем привет. Посоветуйте книгу по ноде для начинающего, на русском)

Всем привет. Посоветуйте книгу по ноде для начинающего, на русском)

"Итан Браун - Веб-разработка с применением Node и Express. Полноценное использование стека JavaScript(Бестселлеры O`Reilly) - 2017"

Спасибо)

#whois - SPA на Vue.js - Full Stack - Опытом - Есть проект на Node.js - Астана - Поиск

Promise это сахар синтаксисный или работает по другому? в тесте показывает что коллбеки быстрее..

Promise это сахар синтаксисный или работает по другому? в тесте показывает что коллбеки быстрее..

а нет оказывается равны)))

результаты разные

ну я могу еще посетовать на то что в этом случае надо каждый раз создавать объект Промисов и возвращать его

всяко тяжелее, чем просто колбек вызвать

Promise это сахар синтаксисный или работает по другому? в тесте показывает что коллбеки быстрее..

Промис это объект отображающий состояние асинхронного процесса, коллбек это функция

Promise это сахар синтаксисный или работает по другому? в тесте показывает что коллбеки быстрее..

Юзайте bluebird промис, он быстрее нативного

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

промисы удобные.

и оно того стоит