Как диагностировать и устранять ситуацию, когда запрос в эндпоинте начинает работать медленно?

1. С чего начать диагностику медленного эндпоинта

Прежде чем оптимизировать, важно понять, как именно проявляется проблема.

1. Какие симптомы:

   • Увеличилось среднее время ответа (latency).

   • Появились таймауты на стороне клиента.

   • Поднялась нагрузка на CPU/БД.

   • Уменьшился throughput (запросов в секунду).

2. Какие данные нужно собрать:

   • Логи с временем начала и окончания запроса.

   • Метрики по эндпоинту (p95, p99 latency).

   • Ошибки и таймауты в логах.

Определение.
Latency (задержка) — время между приходом запроса и отправкой ответа.

2. Локализация проблемного участка внутри эндпоинта

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

Подход:

1. Разбить обработчик на логические шаги:

   • Парсинг входных данных.

   • Запросы к БД.

   • Вызовы внешних API.

   • Обработка, преобразование данных.

   • Формирование ответа.

2. Замерять время выполнения каждого шага:

   • Через логирование.

   • Через встроенные метрики.

Python

import time
from fastapi import APIRouter

router = APIRouter()

@router.get("/items")
async def get_items():
    t0 = time.perf_counter()
    items = await load_items_from_db()
    t1 = time.perf_counter()
    processed = process_items(items)
    t2 = time.perf_counter()
    # логируем тайминги
    print("db:", t1 - t0, "processing:", t2 - t1)
    return processed

По этим логам можно понять, где «провал».

3. Типичные источники проблем

1. База данных:

   • Медленные запросы без индексов.

   • Слишком много JOIN.

   • SELECT * по большой таблице.

   • Лишние UPDATE/INSERT в цикле.

2. Внешние сервисы:

   • Долгий ответ третьей стороны.

   • Последовательные запросы вместо параллельных.

   • Отсутствие таймаутов и ретраев.

3. Тяжёлые вычисления:

   • Сложные циклы и алгоритмы.

   • Ненужные преобразования больших структур.

4. Ошибки в асинхронном коде:

   • Блокирующие вызовы внутри async (например, requests вместо httpx).

   • Забытый await, из-за чего корутина не выполняется вовремя.

4. Инструменты анализа

1. Логирование:

   • Лог времени обработки.

   • Лог SQL-запросов.

2. Профилирование:

   • Профайлеры Python (например, cProfile, py-spy).

   • Профилировщики на уровне инфраструктуры.

3. Анализ SQL:

   • EXPLAIN / EXPLAIN ANALYZE для проблемных запросов.

   • Поиск необходимости индексов.

4. Метрики:

   • Prometheus / Grafana для визуализации латентности.

   • Разделение по эндпоинтам и типам ошибок.

5. Способы устранения проблемы

1. Оптимизация БД:

   • Добавить индексы по нужным фильтрам.

   • Упростить запрос (меньше JOIN, меньше данных).

   • Использовать пагинацию вместо огромных выборок.

2. Оптимизация кода:

   • Убрать лишние вычисления.

   • Не перебирать большие коллекции в Python, если можно сделать это в БД.

   • Избегать повторных вычислений (кэшировать).

3. Внешние сервисы:

   • Добавить таймауты.

   • Делать запросы параллельно (asyncio.gather).

   • Кэшировать результаты там, где это безопасно.

4. Архитектурные изменения:

   • Вынести тяжёлые операции в фоновые задачи (Celery, RQ, background tasks).

   • Разделить один «толстый» эндпоинт на несколько более простых.

   • Ввести кэширование на уровне API (например, Redis).

Python (пример параллельных запросов)

import httpx
import asyncio

async def fetch_all():
    async with httpx.AsyncClient() as client:
        r1, r2 = await asyncio.gather(
            client.get("https://service1"),
            client.get("https://service2"),
        )
        return r1.json(), r2.json()

6. Вывод

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