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

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

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

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

В докладе я расскажу:
  • когда нужно ограничивать пропускную способность сервиса
  • какими свойствами должен обладать алгоритм троттлинга
  • о различных алгоритмах ограничения параллелизма (e.g. SemaphoreSlim)
  • о новом API из .NET 7 System.Threading.RateLimiting
Видеозапись доклада
Появится здесь после конференции
Информация о спикере
Евгений Пешков
Ведущий разработчик, Тинькофф
Занимается высоконагруженными сервисами захвата трафика.

Ранее разрабатывал JetBrains Rider, занимался общей инфраструктурой в Контуре — системой хостинга приложений.

Спикер DotNext, Dump, Codefest, .NET Summit.

Интересуется lock-free алгоритмами и структурами данных, внутренним устройством .NET и операционных систем.
Евгений Пешков
Ведущий разработчик, Тинькофф
Занимается высоконагруженными сервисами захвата трафика.

Ранее разрабатывал JetBrains Rider, занимался общей инфраструктурой в Контуре — системой хостинга приложений.

Спикер DotNext, Dump, Codefest, .NET Summit.

Интересуется lock-free алгоритмами и структурами данных, внутренним устройством .NET и операционных систем.
Все доклады секции