t
у нас тут похожий случай и стратегии такие, что если клиент завален, то события начинают ... скипаться
Size: a a a
2021 October 28
t
и ты такой в логах видишь "скипнуто миллион событий"
c
c
Minoru
у меня не предвидится такой нагрузки, чтобы пришлось что-то скипать :)
у меня не предвидится такой нагрузки, чтобы пришлось что-то скипать :)
c
Minoru
inb4: «не предвидится»
inb4: «не предвидится»
t
"подскажите алгоритм для задачки. Есть канал, по которому приходят задания. Каждое задание приходит отдельным сообщением, но сообщения идут «пачками» случайного размера: то по три, то по одному, то по пять, то ещё сколько-то. На выходе хотелось бы иметь как можно более равномерный поток заданий. Скажем, если на вход поступила пачка из пяти заданий, то в течение последующей секунды надо выдавать по одному заданию каждые 200 мс"
t
нету ТОЙ стороны)
c
Minoru
ок, «чтобы на другом конце входного канала сообразили, что …»
ок, «чтобы на другом конце входного канала сообразили, что …»
c
Minoru
ну Мантикор, ну я же не ТЗ пишу, а в чатике болтаю. Да, сорян, не все формулировки продуманы и вылизаны
ну Мантикор, ну я же не ТЗ пишу, а в чатике болтаю. Да, сорян, не все формулировки продуманы и вылизаны
t
я хочу сказать, что да, в ТЗ изначально ничего не было)
c
portnov
ты ещё скажи что это новые требования и трудоёмкость выставь миноре
ты ещё скажи что это новые требования и трудоёмкость выставь миноре
c
portnov
пусть идёт с аккаунт-менеджером согласовывает
пусть идёт с аккаунт-менеджером согласовывает
c
portnov
Minoru: но скорость обработки, по-моему, лучше всё-таки замерять. Если задания обрабатываются достаточно быстро, то нафига ждать секунду для выборки задания из очереди?
Minoru: но скорость обработки, по-моему, лучше всё-таки замерять. Если задания обрабатываются достаточно быстро, то нафига ждать секунду для выборки задания из очереди?
c
portnov
можно кстати с обеих сторон ограничения поставить
можно кстати с обеих сторон ограничения поставить
c
portnov
что если слишком быстро — то всё-таки немножко под-throttle-ивать
что если слишком быстро — то всё-таки немножко под-throttle-ивать
c
Minoru
дак здесь смысл не в throttle, а в том, чтобы задания немного распределить по времени. Грубо говоря, раз в секунду у меня подходит время выполнять некие проверки. Все они суются в очередь, откуда их тут же вытаскивает толпень воркеров. Эти воркеры выполняют проверки и ломятся писать результаты в SQLite — а у того ограничение на количество одновременных писателей. Хочу распределить проверки по времени, чтобы воркеры получали задания постепенно и имели меньше шансов столкнуться с друг другом
дак здесь смысл не в throttle, а в том, чтобы задания немного распределить по времени. Грубо говоря, раз в секунду у меня подходит время выполнять некие проверки. Все они суются в очередь, откуда их тут же вытаскивает толпень воркеров. Эти воркеры выполняют проверки и ломятся писать результаты в SQLite — а у того ограничение на количество одновременных писателей. Хочу распределить проверки по времени, чтобы воркеры получали задания постепенно и имели меньше шансов столкнуться с друг другом
c
Minoru
в принципе, эту проблему можно решать уровнем выше: перед тем, как пихать пачку заданий в очередь, можно сразу посчитать размер пачки (N) и слать задания с интервалом 1/N
в принципе, эту проблему можно решать уровнем выше: перед тем, как пихать пачку заданий в очередь, можно сразу посчитать размер пачки (N) и слать задания с интервалом 1/N
c
Minoru
но эта мысль пришла мне в голову только сейчас :)
но эта мысль пришла мне в голову только сейчас :)
c
portnov
ну я вроде то же самое предлагаю, только с промежуточным местом для хранения сообщений
ну я вроде то же самое предлагаю, только с промежуточным местом для хранения сообщений
c
portnov
т.е. у тебя есть Queue<Item>, и есть цикл который раз в секунду достаёт одно сообщение и отдаёт воркерам
т.е. у тебя есть Queue<Item>, и есть цикл который раз в секунду достаёт одно сообщение и отдаёт воркерам