Какой объем запросов считается высоким

Что проверяют

Понимаете ли вы, что «высокая нагрузка» зависит от стоимости запроса и ресурсов, и умеете ли говорить о ней метриками. Следом обычно спрашивают, с какой нагрузкой работали вы и что первым упёрлось в потолок.

Как отвечать

Сразу скажите, что универсальной цифры нет. Kestrel на пустом ответе выдерживает сотни тысяч запросов в секунду на одной машине, а эндпоинт с тремя запросами в базу и вызовом внешнего API упрётся в сотни. Нагрузку описывают набором метрик:

• RPS: на инстанс и на систему, средний и пиковый, пики часто в разы выше среднего;
• латентность по перцентилям: p95 и p99, среднее скрывает хвост, на который жалуются пользователи;
• насыщение: CPU, пул потоков, пул соединений с базой, очередь запросов;
• ошибки под нагрузкой: доля 5xx и таймаутов.

Полезен закон Литтла: запросов в работе одновременно примерно RPS, умноженный на время ответа. 1000 RPS при 200 мс дают около 200 параллельных запросов. Если каждый держит соединение с базой, пул в 100 соединений (значение по умолчанию у SqlClient и Npgsql) закончится раньше, чем CPU.

Типичные узкие места в .NET:

• голодание пула потоков: синхронное ожидание асинхронного кода через .Result или .Wait();
• исчерпание сокетов: new HttpClient() на каждый запрос вместо IHttpClientFactory;
• база: N+1 в EF Core, нет индексов, долгие транзакции.

Инструменты: нагрузочные тесты на k6 или NBomber, наблюдение через dotnet-counters и OpenTelemetry. Защита: встроенный rate limiting (AddRateLimiter, с .NET 7), output caching, кеш в IMemoryCache или Redis, горизонтальное масштабирование за балансировщиком.

Где спотыкаются

Называют одно число вроде «1000 RPS это много» без условий. Для статического ответа это мало, для тяжёлого отчёта недостижимо.

Смотрят на среднее время ответа. Сервис со средним 50 мс может отдавать каждый сотый ответ за 5 секунд.

Путают число пользователей с RPS. Десять тысяч человек онлайн дают разную нагрузку в зависимости от того, как часто они кликают.