Развитие проекта arataga: пара рефакторингов по результатам натурных испытаний

В одно время генерировались заявки на запуск хэндлеров. Далее уже хэндлеры на каждой io_threads запускались последовательно.

Соответственно, накладные расходы складываются из двух составляющих:

1. Единомоментная генерация заявок. Если нам нужно сгенерировать их 15K, то это явно будет дороже, чем если нам их нужно сгенерировать 8 (восемь) штук.
2. Суммарное время запуска всех хэндлеров, даже тех, которым прямо сейчас нечего делать.

Если использовать предложенный вами метод, то от пункта №1 вообще не избавляемся (более того, он становится даже более дорогим, т.к. придется запускать еще и фильтры доставки). Пункт №2 так же никуда не уходит, просто он начинает складываться из нескольких составляющих (по количеству шард).

Вашу идею можно было бы развить следующим образом: завести не один mbox для one_second_timer, а N. И заставлять acl_handler-ов подписываться на один из них (случайным образом или посредством какого-то распределения). Для каждого из этих N mbox-ов запускается свой экземпляр one_second_timer. Тогда при наступлении очередного таймерного события единовременная отсылка для каждого из этих N mbox-ов занимала бы гораздо меньше времени.

Как развитие этой идеи можно было бы сделать свой кастомный mbox, который бы сам шардировал подписки. И когда таймер отдает этому mbox-у очередной one_second_timer, то сам mbox отдает one_second_timer сперва первой шарде, затем второй, затем третьей и т.д. Основой для шардирования могли бы стать идентификаторы рабочих нитей, с которых выполняется подписка.

Однако, ключевой момент в том, что если у нас из 15K acl_handler-ов в таймере сейчас заинтересованы только 5K, то оставшиеся 10K вообще никак нельзя трогать.