а , сорян..
n юзеров долбят в апи.
надо одинаковые запросы отсеивать, и оставлять только один. который в случае чего отвалится по таймауту и должен очистить очередь.
тогда это не асинхронная очередь
Aleksand
Андрей
queues.io скорее всего не подойдёт. т.к. хотелось бы чтонить минималистическое. и не на рубях. и не отдельным сервисом а библиотекой. У меня тут не хайлоад никакой )
Андрей
а, ок спасибо, а какая это ?
Aleksand
а, ок спасибо, а какая это ?
ну тебе нужна структура данных простая, чтобы реализовать твою логику
CherryTea
Андрей
защита от того чтобы мой бекенд не долбил другой бекенд )
Андрей
ну тебе нужна структура данных простая, чтобы реализовать твою логику
ок. думал есть бест практики и какойнить queue.js в котором можно задать параметров пачку, длина очереди, таймауты, всякие onUpdate onRelease события и прочее :)
Андрей
ладно разрулю в виде объектов. спс
Андрей
хах )
https://github.com/jessetane/queue
оказывается есть куеуежс .
Aleksand
ладно разрулю в виде объектов. спс
там большего для твоей задачи и не нужно. у тебя логики очереди тут не видно
Андрей
я может не в контексте, т.к. для меня очередь это нечто абстрактное. а инструмент управления очередью это точно чтото с методом push таймаутом событиями, возможностью управлять размером очереди внутри и снаружи (путём не пушения внутрь при определённых условиях).
Андрей
может дело в том что я не пришёл в ноду с какого-то другого языка)
Aleksand
я может не в контексте, т.к. для меня очередь это нечто абстрактное. а инструмент управления очередью это точно чтото с методом push таймаутом событиями, возможностью управлять размером очереди внутри и снаружи (путём не пушения внутрь при определённых условиях).
в твоем случае лучше всего сделать две вещи
- научить бэкэнды вести себя вежливо и не бомбить запросами
- принимать только один запрос а остальным таким же сразу 429 Too Many Requests
Андрей
угу вот эта минимальная асинхронная штука для очередей мне в этом поможет.
https://github.com/jessetane/queue/blob/master/index.js
Aleksand
угу вот эта минимальная асинхронная штука для очередей мне в этом поможет.
https://github.com/jessetane/queue/blob/master/index.js
ну для чего тут тебе очередь непонятно
Андрей
там дело в том, что у каждого юзера может быть 3 типа запроса А Б Ц. и нельзя чтобы я одновременно выполнял АА Б и Ц, а можно чтобы А Б Ц или например только А
Андрей
возможно в будущем мне понадобится очередь не из одного элемента а из двух или из пяти.
Андрей
чтобы можно было позволить юзеру ААААА БББ ЦЦЦЦ
Андрей
но чтобы нельзя было AAAAAAAAAААА
Андрей
надеюсь на яблоках понятно объясняю
Андрей
:))
Aleksand
возможно в будущем мне понадобится очередь не из одного элемента а из двух или из пяти.
тогда тебе нужен нормальный control flow, вот эта либа самая гибкая - http://caolan.github.io/async/
Андрей
она адски большая. я её знаю
Андрей
jessetane/queue её заменяет, и для моей задачи вполне подходит
Anton
всем привет. есть ли кто-нибудь, кто
1) транспайлит серверный js бабелем +
2) пишет для него тесты (напр., mocha)?
какой воркфлоу у вас получается: сначала build, потом тестировать уже собранный апп или тестировать типа как в dev среде?
Anton
просто вроде как логично сначала собирать, а потом уже тестировать сборку, но, например, istanbul, который делает coverage отчёт, в таком случае сообщает, что No coverage information was collected, exit without writing coverage information
Anton
что логично, потому что тестами должен быть покрыт именно исходный код
Anton
а в dev среде в моём случае (как и у многих, подразумеваю) геморройно тестировать, потому что нужно поднимать webpack-dev-server ещё, например
Oleg 🍺
Ребят, упёрся в производительность :c
Oleg 🍺
У меня есть куча инстансов (slave) с вебсокетами, и куча мастеров, в которые прилетают ивенты
Oleg 🍺
Ивенты распределяются по слейв инстансам через IPC
Oleg 🍺
Я хз, что делать(
Alex
Oleg 🍺
)
Oleg 🍺
Мне кажется у меня ивент луп тормозит
Oleg 🍺
16 ядерный сервак, на нём запущено ~10 слейв процессов, при этом загруженность в пик может достигать порядка 1600%
Oleg 🍺
То есть все 16 ядер задействованы, может быть у кого - то был опыт highload?
Oleg 🍺
А ивент луп тормозит, как мне кажется, из за IO операций, которые в ноде очень медленные
Oleg 🍺
Сейчас, уже изучаю Erlang с Elixir)
Oleg 🍺
Там операции по 16us летают
Oleg 🍺
Ах, да, у меня могут прилетать сообщения по 2 мб
Evgeny
А что именно тормозит? Сколько запросов?
Oleg 🍺
Запросов немного, сейчас гляну
Evgeny
Как определили? Можно вывод вмстат посмотреть на минуту?
Oleg 🍺
У меня сейчас нету доступа к проду
Oleg 🍺
Только графана и те метрики которые собираю
Oleg 🍺
Я не определил, а предполагаю, определением мне ещё предстоит заняться
Oleg 🍺
А что именно тормозит? Сколько запросов?
В пик сыпется 600 kpps, то есть 600 тыс пакетов в секунду
Evgeny
А сколько ядер на сетевуху?
Oleg 🍺
Так вот, нужно спроектировать, чтобы система могла обработать до 2 млн пакетов в секунду
Evgeny
И кто их обрабатывает?
Oleg 🍺
Всё обрабатывают слейв процессы
Oleg 🍺
Их около ~200 штук
Oleg 🍺
Разбросаны по нескольким серверам
Oleg 🍺
Может есть статьи на эту тему?
Oleg 🍺
Вот например интересная реализация на erlang https://blog.discordapp.com/scaling-elixir-f9b8e1e7c29b
Vladimir
На какую тему?
Vladimir
Ставь больше серверов и все
Oleg 🍺
Проблема не в серверах, а именно в ноде
Oleg 🍺
Там клиентов вообще мало
Vladimir
Почему ты думаешь что проблема в ноде?
Oleg 🍺
Самый простой вариант, который я придумал и есть в статье выше - это слать батчами пакеты
Evgeny
Чот мне кажется что стоит начать гуглить c10k
Vladimir
Это не значит, что проблема в ноде
Oleg 🍺
Ну когда тебе сообщение прилетает в 2 метра, что ты делать будешь?
Vladimir
Какой то странный вопрос
Vladimir
Будет с ним делать то, что требуется
Vladimir
А что там тебе требуется - я не в курсе
Oleg 🍺
Ну смотри, если у тебя медленный IO, при этом у тебя летают эти сообщения, то тик ивент лупа будет очень долгий и другие асинхронные события будут очень долго ждать своей очереди
Oleg 🍺
https://habrahabr.ru/company/mailru/blog/329258/
Vladimir
Это одна из самых идиотских статей последнего времени
Evgeny
Давайте без грязи тут
Oleg 🍺
))
Evgeny
Просто какие-то метрики хотя бы приведите
Evgeny
Ну просто чтобы понять что проблема не в очереди сетевухи, например
Vladimir
Ты просто выводы с потолка делаешь
Oleg 🍺
Ладно, мне ещё предстоит найти самое слабое место в системе, возможно это не IO, а например IPC
Vladimir
Ну перепиши на С, посмотри что будет
Oleg 🍺
Уже другая команда взялась это делать, я хочу их опередить и сделать оптимизацию раньше них