Как оценивать сроки оптимизации по цифрам до и после

Если запрос выполняется 1,8 секунды, а после оптимизации — 1,2, это ещё не доказывает успех: измениться мог объём данных, кэш или нагрузка. Чтобы оценить срок честно, сначала фиксируют воспроизводимый сценарий, затем измеряют узкое место и только после этого обещают результат. Подход ниже рассчитан на работающие сервисы; примеры с планами запросов относятся к PostgreSQL 16.

Почему оценка оптимизации обычно ошибается

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

Есть и другая ловушка. Разработчик видит один медленный запрос и сразу меняет индекс или структуру кода. В локальном тесте время уменьшается, но в проде запросов становится больше, план меняется, а выигрыш исчезает. Поэтому оценивать нужно не обещание «сделать быстрее», а последовательность проверяемых гипотез.

Честная оценка оптимизации отвечает на два разных вопроса: сколько времени займёт проверка гипотезы и сколько — безопасное внедрение результата.

Что считать до начала работ

Минимальный baseline — исходная точка, с которой сравнивают изменения. Одного среднего времени ответа недостаточно: редкие медленные запросы именно оно скрывает.

• Сценарий. Конкретный URL, SQL-запрос, фоновая задача или пользовательский путь. Укажите параметры и объём входных данных.
• Нагрузка. Число запросов в секунду, параллельность и длительность теста. Если это прод, зафиксируйте временной интервал и долю трафика.
• Распределение задержки. Среднее значение, медиана и хотя бы p95. p95 показывает задержку, ниже которой укладываются 95% измерений.
• Ресурсы. Версии приложения и базы, тип виртуальной машины или контейнера, CPU, память, диски, настройки пула соединений.
• Цена операции. CPU-время, чтение с диска, число обращений к базе, размер ответа, количество внешних вызовов.

В PostgreSQL 16 для отдельного запроса полезно сохранить план выполнения и фактические значения времени и строк через EXPLAIN (ANALYZE, BUFFERS). Не запускайте такой замер без оценки нагрузки: ANALYZE действительно выполняет запрос и может менять состояние данных, если запрос не только читает.

Как превратить задачу в оценку

1. Сформулируйте измеримый результат

Плохая формулировка: «оптимизировать каталог». Хорошая: «снизить p95 ответа каталога с текущего значения при 30 запросах в секунду, не увеличив долю ошибок и расход памяти». Если бизнес-цель неизвестна, не подставляйте её сами. Зафиксируйте техническую: например, уменьшить число запросов к базе или убрать тайм-ауты.

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

2. Разделите работу на гипотезы

Одна крупная задача «ускорить отчёт» скрывает несколько разных работ. Разбейте её на короткие эксперименты:

1. понять, где тратится время: приложение, база, сеть или внешняя система;
2. проверить одну гипотезу — например, план запроса, лишний вызов или сериализацию ответа;
3. повторить baseline в тех же условиях;
4. подготовить изменение и тесты на корректность;
5. прогнать нагрузочный сценарий и сравнить распределение задержки;
6. выпустить изменение с возможностью отката и проверить его на рабочем трафике.

Каждая гипотеза должна иметь ограничение по времени. Например: «до четырёх часов на поиск причины и один безопасный эксперимент». Если за это время причина не подтверждена, оценка пересматривается, а не маскируется переработками.

3. Оцените не только изменение, но и доказательство

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

Как сравнивать «до» и «после»

Сравнивайте только измерения, полученные в сопоставимых условиях. Если до изменения тест шёл на пустом кэше, а после — на прогретом, это два разных эксперимента. Если поменялась версия базы или объём таблицы, отметьте это отдельно.

Для каждого результата сохраните:

• дату и время замера;
• версию приложения, базы и конфигурации;
• объём и характер тестовых данных;
• параллельность и длительность нагрузки;
• p50, p95 и p99, если система чувствительна к хвосту распределения;
• долю ошибок, тайм-аутов и отменённых запросов;
• изменение CPU, памяти, диска и числа соединений.

Результат «среднее время снизилось на 30%» может быть плохим, если p99 выросло втрое. Например, пользователи в среднем получили ответ быстрее, но каждый сотый запрос начал зависать на несколько секунд. Такой релиз нельзя считать безусловным улучшением.

Где подход ломается

Нестабильная нагрузка

Если запросы приходят неравномерно, разница между двумя короткими прогонами может быть следствием очереди, а не оптимизации. Увеличьте длительность измерения, повторите тест несколько раз и сравнивайте одинаковые интервалы или одинаковое число операций.

Слишком маленький тестовый набор

Индекс или алгоритм может выглядеть выгодно на тысячах строк и проигрывать на десятках миллионов. Тестовые данные должны сохранять хотя бы порядок объёма и распределение значений, которые важны для плана запроса.

Оптимизация одного слоя за счёт другого

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

Изменение без обратного плана

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

Как говорить о сроках без самообмана

Используйте диапазон и условия, а не одну красивую цифру. Например: «диагностика займёт от половины до одного рабочего дня, если есть доступ к трассировкам; безопасный эксперимент — ещё до дня; релиз зависит от миграции». Это не слабая оценка. Она показывает, какая неизвестная может изменить план.

Полезно разделять три уровня уверенности:

• Известно. Есть воспроизводимый сценарий, измерения и понятная причина задержки.
• Предполагается. Есть симптом и вероятная причина, но ещё нет подтверждения экспериментом.
• Неизвестно. Нет данных, доступа или возможности повторить проблему.

Для первого уровня можно давать узкий диапазон. Для второго добавляйте время на проверку гипотезы. Для третьего не обещайте срок оптимизации: сначала оцените получение данных. Иначе в план попадёт не работа, а надежда.

Что сделать дальше

Выберите один медленный сценарий и заведите для него карточку: baseline, условия замера, гипотеза, ожидаемый эффект, риск, способ отката и критерий успеха. После изменения сохраните результаты рядом с исходными, а затем поставьте наблюдение на p95, p99, ошибки и нагрузку на узкий ресурс.

Инвалидация кэша, выбор нагрузочного инструмента и построение распределённой трассировки — отдельные темы. Здесь важен следующий шаг: не оптимизировать «сервис вообще», а провести один повторяемый эксперимент с понятной ценой ошибки.

Сноска. Baseline — зафиксированный исходный уровень показателей, с которым сравнивают результат изменения. Без него слово «быстрее» не имеет проверяемого смысла.