Система. Поточная обработка. Таймер, достаточно эффективный для тысяч параллельных таймеров?
Я работаю над механизмом тайм-аута запроса. Мой начальный подход должен был бы создать одну Систему. Поточная обработка. Таймер для каждого запроса. Количество параллельных запросов могло увеличиться к тысячам.
Я задаюсь вопросом, должен ли я вместо этого создать TimeoutScheduler, который внутренне использовал бы только один таймер вместо того, чтобы иметь один на запрос.
Может любой, кто знает внутренности Системы. Поточная обработка. Таймер дает мне некоторое понимание на том, если бы TimeoutScheduler был бы хорошей идеей или если он только попытался бы оптимизировать что-то уже достаточно эффективное.
Примечание: Для моего сценария точность таймера не важна.
(Я сделал некоторый тест производительности с Системой. Поточная обработка. Таймер с большим количеством параллельных таймеров. Это, казалось, масштабировалось хорошо, но я не уверен, окажет ли это нежелательное давление в реальной системе),
4 ответа
Я направлю вас к этому сообщению от Раймонда Чена:
Какое максимальное количество таймеров может создать программа?
Технически нет проблем с созданием тысяч из них. Просто имейте в виду, что они используют глобальные системные ресурсы, поэтому вы в конечном итоге достигнете верхнего предела и / или начнете голодать другие программы (включая саму Windows), если вы сойдете с ума.
Также убедитесь, что вы избавились от таймеров, когда закончите с ними , иначе вы столкнетесь с огромной утечкой ресурсов.
Должен сказать, похоже, что это можно реализовать с помощью одного таймера; просто ведите словарь активных запросов и тайм-аутов и на каждом тике просматривайте весь словарь и проверяйте каждую запись. Вы можете улучшить производительность, составив отсортированный список; таким образом, если в течение следующих 5 минут ничего не происходит по таймауту, метод тика завершится после просмотра первой записи.
В дополнение к вышесказанному, вы также можете динамически настраивать интервал тактов, чтобы срабатывать всякий раз, когда запланирован тайм-аут следующего запроса; затем на каждом тике перенести следующий тик на следующий тайм-аут. Это практически не потребует системных ресурсов (только один таймер), а также будет очень быстрым (как и в случае с вашей идеей с одним таймером на запрос, вы будете запускать дорогостоящий код только тогда, когда запросы действительно истекают).
Несмотря на то, что вы можете создать тысячи таймеров, описанный выше подход будет намного лучше масштабироваться, а также будет намного проще тестировать и поддерживать.
System.Threading.Timer выполняет свой TimerCallback на ThreadPool, создание 1000's может привести к голоданию threadpool.
Используйте делегат TimerCallback, чтобы указать метод, который вы хотите, чтобы выполнял таймер. Делегат таймера задается при создании таймера и не может быть изменен. Метод не выполняется в потоке, создавшем таймер; он выполняется в потоке ThreadPool, предоставляемом системой.
System.Timers.Timer ведет себя аналогичным образом. Лучше всего использовать TimeoutScheduler.
Планировщик тайм-аутов - хорошая идея, но таймеры - это исполнение с самым низким приоритетом. Если речь идет о планировании таймаута, то самым надежным вариантом будет поток, отслеживающий таймауты других потоков и обновления с помощью QueryPerormanceCounter и QueryPerformanceFrequency. Это будут блокирующие классы, но внутри собственного потока это не будет иметь значения. Вы также можете рассмотреть возможность сделать планировщик таймаутов более приоритетным.