Miért gyors a FastAPI, és hogyan tartsd gyorsnak?

Question

Accepted Answer

A FastAPI a leggyorsabb Python keretrendszerek közé tartozik, mert a **Starlette** (egy könnyű ASGI keretrendszer) alapján készült és **async-native**, hatékonyan kezel sok egyidejű I/O-bound kérést. De ahhoz, hogy gyors maradjon, az async-et helyesen kell használni — a leggyakoribb hiba az event loop blokkolása.

## Miért gyors

```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
```

Az async modell a kulcs: míg egy kérés egy adatbázis-lekérdezést vagy API hívást vár, a kiszolgáló másokat kezel — magas áteresztőképességet biztosít az I/O-bound workloads számára.

## Az #1 módszer a gyorsaságnak: ne blokkolj az event loop-ot

```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()
```

Ez a legfontosabb teljesítményszabály: egy blokkoló hívás az `async def` belül az egész event loop-ot blokkolja, kényszerítve a kéréseket, hogy egyenként fussanak. Használj async könyvtárakat az `await`-tel, vagy egy sima `def`-et (thread pool-ban futtatva).

## Gyorsaság megtartása — ellenőrzőlista

```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
```

## Miért fontos

A FastAPI sebessége az elsődleges oka annak, hogy a csapatok válasszák, de ennek a sebességnek az elérése a gyakorlatban az **async helyes használatán** múlik — és a legfontosabb, gyakran sértett szabály a **soha ne blokkolj az event loop-ot**.

Annak megértése, hogy *miért* gyors a FastAPI (async-native ASGI alapok, hatékony I/O egyidejűség, gyors Pydantic v2 mag) tisztázza, hogy annak teljesítményelőnye az egyidejűleg kezelt I/O-bound workloads-ra vonatkozik.

Annak ismerete, hogyan tartsd *gyorsnak* a kritikus gyakorlati készség: a blokkoló hívások `async def`-be helyezésének katasztrofális hibájának elkerülése (amely az összes kérést egy befagyott event loop mögé sorbarendezi), async könyvtárak használata async végpontokkal (vagy sima `def` a blokkoló kódhoz), CPU-munka offloading-ja, gyorsítótárazás, az adatbázis optimalizálása (gyakran a valódi szűk keresztmetszet), és több munkavégző futtatása több mag számára.

Ez az kombináció — az async helyes kihasználása és az igazi szűk keresztmetszetek megtalálása érdekében történő mérés — az, ami lehetővé teszi a FastAPI teljesítménypotenciáljának realizálását, ezáltal fontos senior szintű tudássá válik valóban gyors, skálázható API-k létrehozásához, nem olyan API-kkal helyett, amelyek async-nek tűnnek, de blokkoló kód teljesítményével rendelkeznek.