Почему FastAPI быстрый и как его таким сохранить?

Question

Accepted Answer

FastAPI входит в число самых быстрых фреймворков Python, потому что построен на **Starlette** (легком ASGI-фреймворке) и является **async-native**, эффективно обрабатывая множество одновременных I/O-bound запросов. Но чтобы сохранить его быстрым, нужно правильно использовать async — самая частая ошибка — блокирование event loop.

## Почему это быстро

```text
✓ ASGI + Starlette — a modern async foundation (vs older WSGI sync frameworks)
✓ Async-native — one process handles thousands of concurrent I/O-bound requests
  by overlapping wait times, instead of one-at-a-time
✓ Pydantic v2 — validation/serialization core is now in Rust (very fast)
✓ Minimal overhead per request
```

Асинхронная модель — это ключ: пока один запрос ждет запроса к БД или вызова API, сервер обрабатывает другие — обеспечивая высокую пропускную способность для I/O-bound рабочих нагрузок.

## #1 способ сохранить это быстрым: не блокируйте event loop

```python
# ❌ blocking call inside async def → freezes the event loop, serializing ALL requests
@app.get("/bad")
async def bad():
    return requests.get(url).json()       # SYNC/blocking → kills concurrency

# ✅ use an async client and await it
@app.get("/good")
async def good():
    async with httpx.AsyncClient() as c:
        return (await c.get(url)).json()  # non-blocking

# ✅ OR use a plain def — FastAPI runs it in a thread pool (safe for blocking code)
@app.get("/also-good")
def also_good():
    return requests.get(url).json()
```

Это самое важное правило производительности: блокирующий вызов внутри `async def` блокирует весь event loop, заставляя запросы выполняться один за другим. Используйте async библиотеки с `await` или простой `def` (выполняется в thread pool).

## Сохранение быстродействия — контрольный список

```text
✓ Use async DB drivers / async libraries (httpx, asyncpg) in async endpoints
✓ Run blocking code in plain def (thread pool) or via run_in_executor
✓ Avoid heavy CPU work on the event loop → offload to workers/processes
✓ Add caching (Redis) for expensive repeated work
✓ Optimize the database (fix N+1, add indexes) — often the real bottleneck
✓ Run multiple worker processes (uvicorn/gunicorn workers) to use all CPU cores
✓ Use connection pooling; paginate large results
✓ MEASURE first (profiling, load testing) — fix the actual bottleneck
```

## Почему это важно

Быстродействие FastAPI — основная причина, по которой команды его выбирают, но достижение такой скорости на практике зависит от **правильного использования async** — и самое важное, часто нарушаемое правило — **никогда не блокируйте event loop**.

Понимание *почему* FastAPI быстрый (асинхронная основа ASGI, эффективная I/O-конкурентность, быстрое ядро Pydantic v2) проясняет, что его преимущество производительности применимо к I/O-bound рабочим нагрузкам, обрабатываемым одновременно.

Знание того, как его *сохранить* быстрым — критический практический навык: избегайте катастрофической ошибки размещения блокирующих вызовов в `async def` (что сериализует все запросы за замороженным event loop), используйте async библиотеки в асинхронных эндпоинтах (или простой `def` для блокирующего кода), разгружайте CPU работу, кэширование, оптимизируйте БД (часто это настоящее узкое место), и запускайте несколько рабочих процессов для нескольких ядер.

Эта комбинация — правильное использование async и измерение для выявления реальных узких мест — позволяет вам реализовать потенциал производительности FastAPI, делая это важным знанием уровня senior для создания действительно быстрых и масштабируемых API, а не тех, которые выглядят асинхронно, но работают как блокирующий код.