Каким образом десять параллельных downstream-вызовов могут сделать p99 сквозной задержки существенно хуже p99 каждого отдельного вызова?
Сквозной запрос завершается только после самого медленного из параллельных вызовов, поэтому его задержка определяется максимумом, а не средней задержкой ветвей. Даже если вероятность превышения порога у каждой ветви мала, при десяти ветвях вероятность того, что хотя бы одна из них окажется медленной, заметно возрастает.
Если задержки ветвей независимы и каждая укладывается в свой p99 с вероятностью 99%, вероятность уложиться в этот же порог по всем десяти ветвям равна примерно 0,99^10 = 90,4%. Значит, этот порог будет близок не к p99 сквозного запроса, а примерно к его p90; реальные значения зависят от распределений и корреляций.
Такой эффект стал особенно важен при разбиении приложения на несколько сервисов и использовании компоновки запросов: один пользовательский запрос начал зависеть от множества сетевых и прикладных операций. Обычные средние значения задержки плохо отражали редкие медленные ветви, поэтому для анализа стали применять перцентили и трассировку отдельных запросов.
Параллельный вызов уменьшает сумму обычных задержек по сравнению с последовательным выполнением, но не устраняет хвост распределения. Чем больше независимых зависимостей входит в критический путь, тем сильнее проявляется усиление хвостовой задержки.
Команда может отдельно измерить каждый downstream-сервис, увидеть приемлемый p99 и ошибочно заключить, что агрегирующий endpoint также соблюдает SLA. На практике один медленный вызов задерживает формирование всего ответа, а тайм-аут или ошибка одной ветви могут дополнительно вызвать повторную попытку, деградацию или отказ всего пользовательского запроса.
Риск выше, если количество ветвей меняется, запросы распределены неравномерно или задержки коррелируют из-за общей базы данных, сети, лимитов или инфраструктуры. В таком случае оценка по независимым перцентилям становится лишь приближением.
Пусть задержка каждой параллельной ветви обозначена как (X_i). Если агрегатор ждёт завершения всех ветвей, задержка критического участка равна (\max(X_1, X_2, ..., X_n)). Для независимых ветвей вероятность уложиться в порог (t) равна произведению вероятностей каждой ветви уложиться в этот порог:
(P(\max X_i \leq t) = \prod P(X_i \leq t)).
При десяти ветвях и индивидуальном p99 пороговом значении вероятность успешного укладывания всех ветвей составляет около 90,4%. Поэтому для достижения p99 сквозного запроса каждый downstream обычно должен иметь значительно более строгий целевой перцентиль, причём необходимый запас зависит от числа ветвей и их распределений.
Нельзя просто складывать p99 параллельных вызовов: складывание относится к последовательным операциям. Для последовательных ветвей задержки складываются, а для параллельных берётся максимум; если часть вызовов выполняется параллельно, а часть последовательно, нужно анализировать критический путь всей схемы.
Практический анализ должен включать распределение сквозной задержки, число ветвей, индивидуальные задержки, тайм-ауты и трассировку медленных запросов. Полезно сравнивать задержку агрегатора с максимальной задержкой дочерних вызовов в тех же trace-id, а не с отдельно собранными агрегатами за другой временной период.
Оптимизация может состоять в уменьшении числа ветвей, кэшировании, предварительном объединении данных, ограничении времени ожидания, частичном ответе или использовании деградации. У каждого варианта есть компромиссы: кэш повышает сложность актуализации данных, частичный ответ меняет контракт, а жёсткие тайм-ауты снижают задержку ценой полноты результата.
Агрегирующий endpoint одновременно обращался к десяти сервисам. Каждый downstream имел p99 около 200 мс, но p99 агрегатора был около 430 мс. Трассировка показала, что в большинстве медленных запросов одна из ветвей случайно попадала в хвост задержки; отдельные отчёты по сервисам этого не показывали, поскольку они не измеряли совместное событие в рамках одного пользовательского запроса.
Рассматривались три варианта. Увеличение тайм-аутов было простым, но ухудшало пользовательскую задержку; последовательное кэширование уменьшало число вызовов, но создавало риск устаревших данных; частичный ответ снижал p99, но требовал изменить ожидания клиентов.
Выбрали кэширование редко меняющихся данных и возврат частичного результата для необязательных ветвей, оставив строгий тайм-аут для обязательных. После этого число зависимостей в критическом пути уменьшилось, а p99 агрегатора снизился без увеличения ресурсов downstream. Результат проверяли повторными прогонами с тем же составом нагрузки и по распределению сквозной задержки, а не только по среднему значению.
Нет, одного p99 недостаточно. Перцентиль не содержит полной информации о форме хвоста, а также неизвестны зависимости между задержками ветвей. Для точного анализа нужны совместные измерения в рамках одного запроса, распределения задержек и понимание корреляций.
Тогда сквозная задержка критического участка приблизительно равна сумме задержек отдельных вызовов и локальных накладных расходов. Редкие медленные события могут последовательно накапливаться, поэтому последовательная схема обычно чувствительнее к задержкам зависимостей, чем параллельная, хотя параллельная схема сильнее страдает от роста числа ветвей через оператор максимума.
При общей причине замедления — например, перегрузке базы данных или сетевого сегмента — несколько ветвей могут стать медленными одновременно. Это повышает вероятность медленного сквозного запроса сильнее или иначе, чем предсказывает формула для независимых величин. Поэтому нагрузочное тестирование должно сохранять связь между родительским запросом и его дочерними вызовами и отдельно анализировать периоды общей деградации.