Два теста имеют одинаковый средний RPS, но в одном запросы приходят короткими всплесками. Почему его задержка может быть выше?
Средний RPS не описывает распределение запросов во времени. При всплесках мгновенная интенсивность поступления может временно превысить скорость обработки, поэтому перед сервисом или внутри него накапливается очередь, растут задержки и особенно высокие перцентили.
Ранние оценки производительности часто опирались на средние значения пропускной способности и времени ответа. Такой подход удобен для сравнения, но недостаточен для систем, которые обслуживают неравномерный реальный трафик.
Поэтому в нагрузочном тестировании стали учитывать не только общий объём запросов, но и форму потока: равномерность, всплески, паузы и корреляцию между запросами. Это позволяет проверять поведение очередей, а не только среднюю скорость обработки.
Предположим, сервис способен стабильно обрабатывать 100 запросов в секунду. В равномерном тесте запросы поступают примерно по одному каждые 10 миллисекунд, а в другом тесте те же 6000 запросов за минуту приходят несколькими пачками.
Во время пачки входная скорость может значительно превышать 100 запросов в секунду. Даже если средний RPS за минуту одинаков, очередь растёт, запросы ждут освобождения исполнителей, соединений или других ресурсов, а затем постепенно обслуживаются.
Если проверять только средний RPS и среднюю задержку, проблема может остаться незаметной. На практике пользователи испытывают задержки именно во время всплесков, поэтому ухудшаются p95, p99, тайм-ауты и доля ошибок.
Ключевой фактор — не только средняя интенсивность поступления, но и её кратковременное значение. Когда поток запросов временно быстрее обслуживающей способности, образуется очередь. После окончания всплеска система тратит время на её разгрузку, поэтому повышенная задержка может сохраняться даже при возвращении входного потока к обычному уровню.
Эффект нелинеен: при низкой загрузке очередь быстро исчезает, но при приближении к пределу производительности даже небольшая дополнительная вариативность входного потока способна заметно увеличить время ожидания. Поэтому два теста с одинаковым средним RPS могут давать разные p95 и p99.
Для анализа нужно сравнивать как минимум:
Если цель — воспроизвести реальный трафик, модель должна сохранять его характерную burstiness, то есть неравномерность. Если цель — найти максимальную устойчивую производительность при постоянном потоке, допустима более равномерная подача, но результаты нельзя напрямую трактовать как поведение системы при всплесках.
Сглаживание потока уменьшает шум и помогает сравнивать версии сервиса, однако может скрыть проблемы очередей. Сохранение всплесков повышает реалистичность, но усложняет воспроизводимость и требует фиксировать профиль нагрузки.
Команда сравнивала две версии API при среднем потоке 80 RPS. В первой версии запросы подавались равномерно, во второй — небольшими пачками по 300 запросов каждые несколько секунд. Средняя задержка почти не отличалась, но во втором варианте p99 вырос с 250 до 1400 миллисекунд, а периодически появлялись тайм-ауты.
Рассматривались два варианта. Сгладить поток и оставить только постоянные 80 RPS было проще и обеспечивало хорошую воспроизводимость, но такой тест не отражал фактический профиль клиентов. Сохранить пачки было реалистичнее, однако потребовалось отдельно контролировать размер всплеска, интервал между ними и способность генератора точно выдерживать расписание.
Выбрали второй вариант для проверки пользовательского риска и дополнительно оставили равномерный тест как базовый. Анализ показал, что версия API не стала существенно медленнее при обработке запроса, но хуже справлялась с накоплением очереди во время всплеска. После изменения ограничения параллельной обработки и настройки резервной ёмкости высокие перцентили при том же профиле нагрузки снизились.
Нет. Среднее значение скрывает кратковременные пики и паузы. Нужно сравнивать временной ряд интенсивности на подходящем интервале, распределение межприходовых интервалов, размеры всплесков и длительность периодов повышенной подачи. Иначе одинаковый средний RPS может соответствовать совершенно разной нагрузке на очереди и пулы ресурсов.
CPU может быть не единственным ограничивающим ресурсом. Очередь может образовываться перед пулом соединений, ограниченным числом рабочих слотов, хранилищем или сериализованной критической секцией. Кроме того, после всплеска CPU способен быстро освободиться, тогда как накопившиеся запросы ещё продолжают ждать. Поэтому средняя загрузка за интервал не обязательно отражает кратковременное насыщение и состояние очереди.
Оно оправдано при изучении базовой пропускной способности и сравнении изменений в условиях контролируемой постоянной нагрузки. Искажение возникает, если система в эксплуатации получает всплески, а тест проверяет только равномерный поток: такой тест может не выявить рост очередей, тайм-ауты и деградацию высоких перцентилей. На практике полезно проводить оба сценария и явно указывать, какой аспект производительности измеряет каждый из них.