Miksi FastAPI on nopea ja kuinka pidät sen nopeana?

Question

Accepted Answer

FastAPI on yksi nopeimmista Python-kehyksistä, koska se on rakennettu **Starlettelle** (kevyt ASGI-kehys) ja on **async-native**, käsitellen tehokkaasti monia samanaikaisia I/O-bound-pyyntöjä. Mutta pitääksesi sen nopeana, sinun on käytettävä async-koodia oikein — yleisin virhe on event loopin estäminen.

## Miksi se on nopea

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

Async-malli on avain: kun yksi pyyntö odottaa tietokannan kyselyä tai API-kutsua, palvelin käsittelee muita — tuottaen korkean läpäisykyvyn I/O-bound-kuormille.

## Ensisijainen tapa pitää se nopeana: älä estä event loopia

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

Tämä on yksittäin tärkein suorituskykysääntö: estävä kutsu `async def`:n sisällä estää koko event loopin, pakottaen pyynnöt suorittamaan yksi kerrallaan. Käytä async-kirjastoja `await`:n kanssa tai tavallista `def`:ää (suoritetaan säikevirta-allokissa).

## Nopeuden säilyttäminen — tarkistuslista

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

## Miksi sillä on merkitystä

FastAPI:n nopeus on pääasiallinen syy siihen, miksi tiimit valitsevat sen, mutta nopeuden saavuttaminen käytännössä riippuu **async:n oikeasta käytöstä** — ja tärkein, usein rikottu sääntö on **älä koskaan estä event loopia**.

Ymmärtäminen *miksi* FastAPI on nopea (async-native ASGI-pohja, tehokas I/O-samankaltaisuus, nopea Pydantic v2 -ydin) selventää, että sen suorituskykyhyöty koskee samanaikaisesti käsiteltäviä I/O-bound-kuormia.

Tietäminen kuinka *pitää se* nopeana on kriittinen käytännöllinen taito: välttää tuhoisa virhe, jossa asetetaan estäviä kutsuja `async def`:n sisään (joka sarjaistaa kaikki pyynnöt jäätyneen event loopin takana), käyttää async-kirjastoja async-päätepisteissä (tai tavallista `def`:ää estävälle koodille), siirtää CPU-työtä, välimuistin käyttö, tietokannan optimointi (usein todellinen pullonkaula), ja useiden työntekijöiden suorittaminen useille ytimille.

Tämä yhdistelmä — async:n oikea hyödyntäminen ja mittaaminen todellisten pullonkaulojen löytämiseksi — on se, mikä mahdollistaa FastAPI:n suorituskykypotentiaalin toteuttamisen, mikä tekee siitä tärkeää ylemmän tason tietoa genuinisti nopeita, skaalautuvia API:ta varten sen sijaan, että ne näyttävät async-koodia, mutta suorittavat kuin estävä koodi.