{
  "index": 60,
  "slug": "editorial-2026-05-practice-systems-performance",
  "title": "Критический путь запроса: как найти задержку и не перепутать её с причиной",
  "excerpt": "Запрос медленный, хотя CPU свободен. Разбираем end-to-end путь, отделяем очередь от работы и задаём проверку, после которой оптимизацию можно обсуждать без догадок.",
  "contentHtml": "<p>Пользователь ждёт ответ десять секунд, а CPU сервиса держится на двадцати процентах. Команда меняет SQL, увеличивает пул потоков или поднимает таймаут. Симптом иногда маскируется, но путь не становится быстрее. Цена ошибки — релиз без эффекта, дополнительная нагрузка и потеря исходного сигнала. Следующий инженер уже не видит, что именно сравнивали.</p>\n<p>Низкая загрузка CPU не опровергает медленный запрос. End-to-end время включает ожидание, работу и вызовы зависимостей. Чтобы выбрать действие, нужно разложить один путь на связанные интервалы и удержать одну границу сравнения. Учебные значения ниже не являются измерениями production-системы. Они показывают способ рассуждать.</p>\n<h2>Механизм: время ответа состоит не только из работы</h2>\n<p>Root span задаёт границу от приёма запроса до ответа. Дочерний span показывает названную операцию внутри этой границы. Запрос может ждать admission queue, свободное соединение, блокировку, диск, DNS, TLS или ответ удалённого сервиса. Пока он ждёт, CPU может почти не работать.</p>\n<p>Название интервала ограничивает вывод. <code>queue-wait</code> означает отдельно записанное ожидание в очереди. <code>database-execution</code> означает интервал вызова базы в этой trace. <code>external-dependency</code> означает границу внешнего вызова. Ни одно из этих названий само по себе не доказывает причину задержки. Если ожидание не размечено, его нужно оставить неизвестным.</p>\n<p>Критический путь — это не рейтинг сервисов и не сумма всех span. Это временная цепь внутри одного root span. Связность важнее красивого графика: у каждого дочернего span должен существовать parent, начало не должно быть позже конца, а единицы времени должны совпадать. Если два вызова идут параллельно, их длительности нельзя складывать как последовательные.</p>\n<h2>Учебный пример: один root, три названных интервала</h2>\n<p>Рассмотрим условную trace <code>fixed-trace-01</code>. Root длится 1&nbsp;000 units. Очередь занимает 520, вызов БД — 150, внешний каталог — 200. Промежутки между интервалами не получили отдельного объяснения. Поэтому их нельзя автоматически назвать сетью или дополнительной работой.</p>\n<div class=\"table-scroll\"><table><caption>Состав одного учебного end-to-end пути</caption><thead><tr><th scope=\"col\">Сегмент</th><th scope=\"col\">Роль</th><th scope=\"col\">Интервал</th><th scope=\"col\">Длительность</th><th scope=\"col\">Что можно сказать</th></tr></thead><tbody><tr><td>fixed-admission-queue</td><td>queue-wait</td><td>40–560</td><td>520</td><td>Самый длинный названный сегмент этой записи</td></tr><tr><td>fixed-db-call</td><td>database-execution</td><td>570–720</td><td>150</td><td>Интервал вызова БД в этой trace</td></tr><tr><td>fixed-catalog-call</td><td>external-dependency</td><td>730–930</td><td>200</td><td>Интервал внешнего вызова в этой trace</td></tr><tr><td>fixed-gateway</td><td>end-to-end</td><td>0–1&nbsp;000</td><td>1&nbsp;000</td><td>Граница пути, а не объяснение причины</td></tr></tbody></table></div>\n<figure><img src=\"/assets/editorial/2026/systems-performance-2026-critical-path-waterfall.svg\" alt=\"Учебный waterfall: очередь, вызов БД и внешний каталог внутри end-to-end границы\" loading=\"lazy\" /><figcaption>Учебная схема показывает порядок проверки: сначала root и названные интервалы, затем границы вывода. Она не изображает production latency.</figcaption></figure>\n<p>В этой записи <code>fixed-admission-queue</code> длиннее двух других названных сегментов. Это единственный прямой вывод о порядке длительностей. Нельзя из него заключить, что очередь является bottleneck при другой нагрузке, что изменение gateway ускорит пользователя или что БД не требует исследования. Для любого такого утверждения нужна отдельная проверка.</p>\n<h2>Пример проверки структуры</h2>\n<p>Код ниже работает с заранее заданным объектом. Он не обращается к сети, базе, часам, профайлеру или телеметрии. Числа условны. Пример проверяет связность и интервалы, а не показывает результат реального сервиса.</p>\n<pre><code>const trace = {\n  root: { id: 'root-01', start: 0, end: 1000 },\n  spans: [\n    { id: 'queue-01', parent: 'root-01', role: 'queue-wait', start: 40, end: 560 },\n    { id: 'db-01', parent: 'root-01', role: 'database-execution', start: 570, end: 720 },\n    { id: 'catalog-01', parent: 'root-01', role: 'external-dependency', start: 730, end: 930 }\n  ],\n  load: { cohort: 'fixed-load-a', requests: 12, concurrency: 3, shape: 'fixed-read-shape-a' }\n};\n\nfunction review(input) {\n  const ids = new Set(input.spans.map((span) =&gt; span.id));\n  const connected = input.spans.every((span) =&gt;\n    span.parent === input.root.id || ids.has(span.parent)\n  );\n  const timed = input.spans.every((span) =&gt;\n    Number.isFinite(span.start) &amp;&amp; Number.isFinite(span.end) &amp;&amp;\n    span.end &gt;= span.start\n  );\n\n  if (!connected) return { status: 'stop-incomplete-trace' };\n  if (!timed) return { status: 'stop-invalid-interval' };\n  return { status: 'observation-ready', effect: 'not-claimed' };\n}\n\nconsole.log(review(trace));</code></pre>\n<p><code>observation-ready</code> здесь означает только, что запись связна и содержит корректные условные интервалы. Если <code>parent</code> равен <code>missing-01</code>, результат должен быть <code>stop-incomplete-trace</code>. Если начало больше конца, функция должна остановиться. Отрицательный путь не является исключением из метода. Он показывает, что неполный материал нельзя превращать в уверенный диагноз.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Симптом → причина → проверка → действие</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Возможная причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>CPU низкий, запрос медленный</td><td>В end-to-end время вошло ожидание</td><td>Разделить queue-wait, локальную работу и дочерние вызовы</td><td>Назвать только покрытые span; остаток оставить unknown</td></tr><tr><td>Длинный span совпал с пиком latency</td><td>Span включает ожидание upstream или retry</td><td>Проверить parent/child, повторные вызовы и дочерние интервалы</td><td>Не объявлять span причиной без отдельного сигнала</td></tr><tr><td>Второй прогон короче первого</td><td>Изменилась нагрузка или форма входа</td><td>Сверить cohort, requests, concurrency и shape</td><td>Снять сравнение и повторить на общей границе</td></tr><tr><td>Есть root, но нет parent у дочернего span</td><td>Потеря записи или неверная связь ID</td><td>Проверить полный экспорт и уникальность идентификаторов</td><td>Вернуть stop; не дорисовывать дерево по времени</td></tr><tr><td>После изменения есть одна короткая запись</td><td>Нет baseline и распределения наблюдений</td><td>Повторить тот же сценарий и сохранить контроль</td><td>Назвать observation, а не improvement</td></tr></tbody></table></div>\n<h2>Как не спутать наблюдение с причинностью</h2>\n<p>Длинный интервал сообщает, что в конкретной записи он длинный. Он не сообщает, почему это произошло и какое изменение его сократит. Очередь может зависеть от admission policy или ограниченного ресурса. Вызов БД может ждать соединение до начала исполнения. Внешний вызов может включать локальную подготовку. Одна trace не выбирает между этими объяснениями.</p>\n<p>Полезно разделять три фразы. Наблюдение: «queue-wait занимает 520 units в <code>fixed-trace-01</code>». Гипотеза: «правило допуска создаёт часть ожидания». Проверка: «сравнить заранее определённые записи с теми же cohort, requests, concurrency и shape». Перескакивать от первой фразы к третьей нельзя. Тем более нельзя сразу объявлять эффект изменения.</p>\n<p>Та же граница действует для базы. <code>database-execution = 150</code> — не диагноз SQL, не рекомендация индекса и не оценка бюджета. Если команда хочет исследовать запрос, она формулирует новый вопрос и сохраняет текущую запись как baseline только после проверки сопоставимости. Уменьшение знакомого локального шага не становится правильным действием из-за того, что его проще измерить.</p>\n<h2>Что значит сопоставимая нагрузка</h2>\n<p>Baseline и candidate можно сравнивать только внутри явно названной контрольной границы. В учебном примере это <code>fixed-load-a</code>, 12 логических запросов, concurrency 3 и <code>fixed-read-shape-a</code>. Если второй прогон использует 24 запроса, concurrency 6 или другую форму входа, он отвечает на другой вопрос. Более короткий root не доказывает ускорение.</p>\n<p>Смена одного поля уже важна. Если выросла concurrency, очередь может измениться без изменения кода. Если изменилась форма данных, база может выбрать другой план. Если другой cohort пришёл из другого окна, кэш и внешняя зависимость могли иметь иное состояние. Запись должна сделать эти условия видимыми, а не прятать их в подписи графика.</p>\n<p>Отдельно проверяйте параллельность. Дочерние span могут пересекаться. В таком случае их сумма превысит время root и не покажет стоимость пути. Сначала определите временную зависимость. Если это невозможно, оставьте вывод на уровне «интервалы пересекаются» и не выбирайте самый большой span как причину.</p>\n<h2>Порядок действий</h2>\n<ol><li>Зафиксируйте исходный симптом: маршрут, метод, статус, длительность, размер ответа, время и идентификатор запроса.</li><li>Сохраните один trace до изменения кода или конфигурации. Отметьте root, дочерние операции, пропуски и неизвестные интервалы.</li><li>Проверьте parent/child-связи, границы интервалов и единицы времени. Отдельно отметьте overlap.</li><li>Выпишите контрольную границу: cohort, число логических запросов, concurrency и форму входных данных.</li><li>Отделите ожидание от исполнения БД и внешнего вызова. Не называйте неразмеченный остаток причиной.</li><li>Сформулируйте гипотезу и проверку, которая может её опровергнуть. Один длинный span не заменяет такую проверку.</li><li>Прогоните отрицательный случай: отсутствующий parent, некорректный интервал, unknown-delay или другая нагрузка должны вернуть точный stop.</li><li>Измените один фактор только после фиксации baseline. Повторите тот же сценарий на той же контрольной границе.</li><li>Сравните исходный симптом с candidate и проверьте соседние сигналы: ошибки, таймауты, очередь, throughput и потребление ресурсов.</li></ol>\n<h2>Что делать с отрицательным путём</h2>\n<p>Если trace неполная, остановитесь на <code>stop-incomplete-trace</code>. Если ожидание помечено только как <code>unknown-delay</code>, не называйте его очередью. Если нагрузка отличается, верните <code>stop-incomparable-load</code>. Если в записи уже есть утверждение «стало быстрее», но нет сопоставимого контроля, снимите claim и сохраните только наблюдение.</p>\n<p>Такая остановка экономит время. Неполный trace легко вставить в убедительный рассказ и трудно разобрать после нескольких изменений. Именованная причина stop сохраняет недостающий факт: нужно восстановить parent, назвать ожидание или выровнять нагрузку. Отказ от вывода точнее, чем правдоподобное объяснение пустого места.</p>\n<h2>Ограничения</h2>\n<p>Sampling может убрать нужный span. Collector может потерять событие или доставить его не по порядку. Асинхронный worker может продолжить работу после root. Часы узлов могут расходиться. Retry может создать несколько операций с похожими именами. Эти условия не делают trace бесполезной, но снижают силу вывода. Ограничение нужно записать рядом с наблюдением.</p>\n<p>Waterfall не измеряет throughput, хвост распределения, стоимость соединений, поведение при исчерпании пула или влияние кэша. Он не задаёт SLA и не заменяет нагрузочный тест. RFC 9110 описывает семантику HTTP, а не бюджет latency приложения. Для эксплуатационного решения нужны отдельные измерения, контрольные группы и критерии остановки.</p>\n<p>Учебный код нельзя подключать к реальной телеметрии без новой проверки. Он использует одну запись, фиксированные числа и заранее известные поля. Он не проверяет экспорт, прокси, клиентские повторы или права доступа. Production-результат появляется только после отдельного эксперимента с описанной средой.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Разбор готов, если другой инженер без устных пояснений может найти root, проверить parent/child-связи и интервалы, увидеть контрольную границу, отличить названную задержку от unknown и воспроизвести stop на неполной trace или несопоставимой нагрузке. Это критерий качества evidence, а не обещание ускорения.</p>\n<p>Изменение можно оценивать отдельно, когда baseline и candidate сопоставимы, изменён один фактор, исходный симптом измерен тем же способом, а результат не маскирует ошибку ростом таймаута или потерей сигнала. До этого корректный итог звучит так: «В <code>fixed-trace-01</code> при <code>fixed-load-a</code> queue-wait — самый длинный названный сегмент. Эффект изменения не заявлен». Другой инженер должен получить тот же вывод из той же записи.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://opentelemetry.io/docs/concepts/signals/traces/\" target=\"_blank\" rel=\"noopener noreferrer\">OpenTelemetry: Traces</a> — официальное описание trace и span; источник не доказывает причинность конкретной задержки.</li><li><a href=\"https://www.w3.org/TR/trace-context/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C Trace Context</a> — стандарт передачи trace-контекста между границами; он не гарантирует полноту сбора.</li><li><a href=\"https://www.rfc-editor.org/rfc/rfc9110.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 9110: HTTP Semantics</a> — семантика HTTP-запросов и ответов; RFC не задаёт SLA или бюджет времени приложения.</li></ul>"
}