У всех периодически случаются факапы на бекенде. Части этих факапов можно избежать, если провести нагрузочное тестирование, определить пределы возможностей сервиса и заранее ограничить количество одновременно обрабатываемых запросов (троттлинг). Это позволяет сгладить неравномерность нагрузки и справиться с обработкой хотя бы части запросов, что гораздо лучше полного падения сервиса.

Решить задачу троттлинга помогает примитив синхронизации под названием семафор. Он пропускает внутрь заданное количество потоков, а остальные ставит в очередь. Однако, современные приложения — асинхронные, использовать в них обычный семафор — неэффективно, и здесь у разработчиков фреймворков и highload сервисов появляется необходимость выбора алгоритма реализации семафора, работающего не на уровне потоков, а на уровне асинхронных задач. Неудачно выбранный алгоритм ещё больше нагрузит сервис, который и так работает под нагрузкой на пределе возможностей.

В докладе я расскажу:

• когда нужно ограничивать пропускную способность сервиса
• какими свойствами должен обладать алгоритм троттлинга
• о различных алгоритмах ограничения параллелизма (e.g. SemaphoreSlim)
• о новом API из .NET 7 System.Threading.RateLimiting