Performance of Flask Vs FastAPI

Publié le 13 août 2026 par davidhxxx

Architectural Foundations: WSGI vs ASGI

– WSGI (Flask) vs ASGI (FastAPI) overview:
Flask relies on the WSGI (Web Server Gateway Interface) standard, designed for synchronous request-response cycles.
FastAPI relies on the ASGI (Asynchronous Server Gateway Interface) standard, built natively for non-blocking asynchronous execution.

– Execution model comparison:
Flask delegates concurrency to multi-process or multi-thread worker pools managed by WSGI servers like Gunicorn.
FastAPI handles concurrency on a single thread per worker using an asynchronous Event Loop (powered by asyncio and uvloop).

– Server deployment configuration examples: 

# 1. Flask Production Execution (Gunicorn with native Threads)
# gunicorn --workers 4 --threads 10 --bind 0.0.0.0:8000 wsgi:app
 
# 2. FastAPI Production Execution (Uvicorn with Async Worker Pool)
# uvicorn main:app --workers 4 --host 0.0.0.0 --port 8000

Low-Level Mechanics: Threads, GIL, and I/O

– The CPython GIL and I/O operations:
Python’s Global Interpreter Lock (GIL) prevents multiple threads from executing Python bytecode simultaneously within the same process.
However, during network or disk I/O (Database queries, HTTP calls), CPython’s underlying C code executes the Py_BEGIN_ALLOW_THREADS macro.
This releases the GIL, allowing other Python threads to execute on the CPU while the first thread waits for network packets.

– Kernel execution states under Linux:
In OS theory, a thread waiting for I/O is in the BLOCKED state.
Inside the Linux Kernel, this state is tracked as SLEEPING (specifically TASK_INTERRUPTIBLE).
While sleeping, the thread consumes 0% CPU, allowing the OS kernel to perform a context switch and assign CPU core time to active threads.

– C-level I/O execution loop under CPython: 

/* Under the hood CPython C code during I/O calls (e.g. socket recv) */
 
Py_BEGIN_ALLOW_THREADS  // 1. Releases the GIL for other Python threads
recv(socket_fd, buffer, size, 0); // 2. POSIX System Call: Kernel puts thread to SLEEP
Py_END_ALLOW_THREADS    // 3. Re-acquires the GIL once network data arrives

Use Case 1: Standard REST APIs (Short I/O with Brief CPU Overhead)

– Scenario setup:
A traditional REST API route with a total execution time of 50 ms split into:
– T_CPU = 20 ms of pure Python processing (routing, parsing, Pydantic/dataclass validation, JSON serialization).
– T_IO = 30 ms of network wait time (Database queries, Redis cache reads).
The server receives a sudden burst of 1,000 concurrent requests (1K burst) on a 4-core CPU machine.

– Absolute physical hardware limit:
Total CPU time required to process 1,000 requests is 1,000 req * 20 ms = 20,000 ms (20 seconds of cumulative core execution).
On a 4-core machine, max sustained throughput is strictly capped by hardware: 4 cores * (1000 ms / 20 ms CPU) = 200 req/sec.

1) With Flask (WSGI + Gunicorn Threads)

– Mathematical queuing analysis:
Assume a Gunicorn setup running 4 workers with 10 threads each (4 workers * 10 threads = 40 concurrent threads on a 4-core CPU).

– During T_IO (30 ms), threads release the GIL and sleep: CPU cores are released for active threads.

– CPU Bottleneck: With 40 threads competing for 4 physical CPU cores, core saturation keeps CPU utilization near 100%.

– Queue clearing time (Total Drain Time): 1,000 requests / 200 req/sec = 5.0 seconds total processing time to completely empty the queue.

– Client experience during 1K peak:
– First clients receive responses in ~50 to 100 ms.
– 500th client receives their response in ~2.5 seconds.
– 1,000th client receives their response in ~5.0 seconds.
– Error rate: 0% errors (assuming client timeout > 5s). All 1,000 requests wait safely in the Linux Socket Backlog without dropping connections.

– Standard Flask thread implementation: 

from flask import Flask, jsonify
import time
 
app = Flask(__name__)
 
@app.route("/api/v1/resource")
def get_resource():
    # 1. T_CPU: Pure Python processing (routing, parsing)
 
    # 2. T_IO: Database/Redis call releasing the GIL (30ms sleep)
    time.sleep(0.03) 
 
    # 3. T_CPU: JSON serialization & response return (20ms CPU total)
    return jsonify({"status": "success", "data": "payload"})

– Conclusion:
Flask hits the hard physical CPU limit of 200 req/sec.
Thread context-switching adds minor kernel overhead, requiring 5.0 seconds to fully drain the burst.
To absorb this 1,000-request burst without latency degradation (e.g. under 1 second), horizontal scaling via a Load Balancer is mandatory (2 or 3 instances are enough).

2) With FastAPI (ASGI + Async Event Loop)

– Mathematical queuing analysis:
Assume an Uvicorn setup running 4 workers (1 worker process per CPU core, each running a single-threaded Event Loop).

– During T_IO (30 ms), the Event Loop yields control via await to pick up other incoming requests on the same worker thread.

– CPU Bottleneck: Asynchronous I/O does not generate free CPU cycles. Because each request still requires 20 ms of single-threaded Python CPU execution, the Event Loop is locked for 20 ms per request. The maximum throughput ceiling remains identical at 200 req/sec.

– Queue clearing time: 1,000 requests / 200 req/sec = 5.0 seconds total wall-clock time.

– Client experience during 1K peak:
Identical latency profile (~50 ms up to ~5.0s for the 1,000th client), but achieved with a significantly lower memory footprint (~20 MB RAM vs ~80 MB+ for Flask threads) and zero OS thread overhead.

– Asynchronous FastAPI implementation: 

from fastapi import FastAPI
import asyncio
 
app = FastAPI()
 
@app.get("/api/v1/resource")
async def get_resource():
    # 1. T_CPU: Pure Python processing & Pydantic parsing
 
    # 2. T_IO: Non-blocking async Database/Redis call (30ms async sleep)
    await asyncio.sleep(0.03)
 
    # 3. T_CPU: Serialization & response return (20ms CPU total)
    return {"status": "success", "data": "payload"}

– Conclusion:
Async execution cannot bypass hardware physics when CPU processing is present.
Echoing Flask, To absorb this 1,000-request burst without latency degradation (e.g. under 1 second), horizontal scaling via a Load Balancer is mandatory (2 or 3 instances are enough). FastAPI’s primary advantage here remains its RAM efficiency, allowing higher worker density per cloud instance at scale.

Use Case 2: Long I/O & WebSockets

– Scenario setup:
An application maintaining long-lived connections or fetching data from 5 external third-party APIs taking 2 seconds each.
The server receives a sudden burst of 1,000 concurrent requests (1K burst) on a 4-core CPU machine.
The requests consume very low CPU time (T_CPU = 5 ms total).

1) With Flask (WSGI + Gunicorn Threads)

– Mathematical queuing analysis:
Assume a Gunicorn setup running 4 workers with 10 threads each (4 workers * 10 threads = 40 concurrent threads).
Executing 5 external API calls sequentially takes 2s * 5 = 10 seconds total blocking time per request.

– Required sequential cycles (waves): To process 1,000 requests in groups of 40, the server must run 25 consecutive cycles (1,000 / 40 = 25 cycles).

– Queue clearing time (Total Drain Time): 25 cycles * 10 seconds = 250 seconds (~4.1 minutes).

– Client experience during 1K peak:
– Requests 1 to 120: Served sequentially across 3 waves (Clients wait between 10s and 30s).
– All requests beyond the 120th position: Must wait in the queue for over 30 seconds before a thread becomes free.
– Failure mode: Reverse proxies (Nginx/Cloudflare) enforce a 30-second timeout threshold. As a result, all requests beyond the 120th position (880 out of 1,000 requests, or 88% of total traffic) fail with a 504 Gateway Timeout.

– Standard Flask sequential implementation: 

from flask import Flask, jsonify
import requests
 
app = Flask(__name__)
 
@app.route("/api/v1/aggregate")
def aggregate_external_data():
    # Executes 5 external API calls sequentially (2s * 5 = 10s total blocking time)
    r1 = requests.get("https://api1.example.com/data").json()
    r2 = requests.get("https://api2.example.com/data").json()
    r3 = requests.get("https://api3.example.com/data").json()
    r4 = requests.get("https://api4.example.com/data").json()
    r5 = requests.get("https://api5.example.com/data").json()
    return jsonify({"responses": [r1, r2, r3, r4, r5]})

– Conclusion:
Flask struggles under long I/O workloads. Holding 1,000 sequential connections ties up thread pools, forcing requests into long queues that inevitably trigger 504 Gateway Timeouts for the majority of users.

2) With FastAPI (ASGI + Async Event Loop)

– Mathematical queuing analysis:
FastAPI fires all 5 external API calls concurrently in parallel using asyncio.gather for every incoming request.
Total wall-clock time per request drops from 10 seconds down to 2 seconds.

– Concurrency behavior: All 1,000 incoming requests are registered in the Event Loop simultaneously with zero OS thread overhead.

– Queue clearing time: ~2.0 to 3.0 seconds total.

– Client experience during 1K peak:
– All 1,000 clients receive their aggregated responses in ~2 seconds.
– Error rate: 0% errors. Zero gateway timeouts.
– Memory footprint: Ultra-low (~25 MB RAM total vs 2 GB+ for 1,000 OS threads).

– Asynchronous FastAPI concurrent I/O implementation: 

from fastapi import FastAPI
import asyncio
import httpx
 
app = FastAPI()
 
@app.get("/api/v1/aggregate")
async def aggregate_external_data():
    async with httpx.AsyncClient() as client:
        # Executes 5 external API calls concurrently in 2s total instead of 10s
        results = await asyncio.gather(
            client.get("https://api1.example.com/data"),
            client.get("https://api2.example.com/data"),
            client.get("https://api3.example.com/data"),
            client.get("https://api4.example.com/data"),
            client.get("https://api5.example.com/data")
        )
    return {"responses": [r.json() for r in results]}

– Conclusion:
This is FastAPI’s absolute superpower. By executing I/O calls concurrently, wall-clock latency drops from 10s to 2s, allowing 1,000 concurrent requests to be served almost instantly with negligible RAM usage.

Use Case 3: Heavy CPU & NumPy Workloads

– Scenario setup:
An API endpoint performing heavy mathematical computations (NumPy matrix operations, ML inference) taking 500 ms of pure CPU time.
The server receives a sudden burst of 1,000 concurrent requests (1K burst) on a 4-core CPU machine.

– Absolute hardware limitation: 4 cores * (1000 ms / 500 ms) = 8 req/sec max sustained capacity.

1) With Flask (WSGI + Gunicorn Threads)

– Mathematical queuing analysis:
Max processing throughput is strictly capped by hardware at 8 requests per second across all 4 CPU cores.

– Thread Contention Overhead: Having 40 OS threads (4 workers * 10 threads) simultaneously fighting for 4 physical CPU cores triggers heavy OS context switching, artificially degrading throughput below 8 req/sec.

– Queue clearing time (Total Drain Time): 1,000 requests / 8 req/sec = 125 seconds (~2.08 minutes).

– Client experience during 1K peak:
– Requests 1 to 240: Processed sequentially over the first 30 seconds at 8 req/sec.
– All requests beyond the 240th position: Must wait in the queue for over 30 seconds before receiving CPU time.
– Failure mode: Reverse proxies (Nginx/Cloudflare) enforce a 30-second timeout threshold. As a result, all requests beyond the 240th position (760 out of 1,000 requests, or 76% of total traffic) fail with a 504 Gateway Timeout.
– Total Server Saturation: Because all 4 workers and 40 threads are 100% busy computing, any lightweight route (like /healthcheck) is queued at the back of the 1,000 requests and also times out.

– Standard Flask CPU task implementation (Blocking – BAD): 

from flask import Flask, jsonify, request
import numpy as np
 
app = Flask(__name__)
 
@app.route("/api/v1/compute", methods=["POST"])
def compute():
    payload = request.json
    data = np.array(payload)
    # Pure CPU calculation executed directly inside the HTTP thread worker
    result = np.linalg.inv(data).tolist()
    return jsonify({"result": result})

– Conclusion:
Flask cannot bypass hardware physics. Executing CPU-bound tasks directly inside HTTP workers causes thread starvation, 76% Gateway Timeouts, and blocks lightweight routes.
Using 2 or 3 instances loadbalanced are not enough because the gap to get response under 1 sec is huge ( All requests beyond the 240th position: Must wait in the queue for over 30 seconds before receiving CPU time).
The required architectural pattern is to decouple HTTP request handling from CPU execution by offloading workloads to asynchronous background task queues backed by a message broker.

2) With FastAPI (ASGI + Async Event Loop)

– Mathematical queuing analysis:
If a CPU-bound task is declared with async def, it locks the single-threaded Event Loop for 500 ms per request, freezing all other incoming traffic.

– Offloading locally via ProcessPoolExecutor keeps the Event Loop responsive for lightweight routes (e.g. /healthcheck stays 100% available). However, overall CPU calculation throughput remains strictly bounded by hardware at 8 req/sec.

– Queue clearing time: Still 125 seconds across 4 cores. All requests beyond the 240th position still trigger a 30-second 504 Gateway Timeout.

– Client experience during 1K peak:
– Un-offloaded async def: Event Loop freezes, 76% timeouts, and /healthcheck fails completely.
– Offloaded via ProcessPoolExecutor: Healthchecks remain responsive, but 76% of compute requests still time out due to physical hardware saturation.

– Offloaded FastAPI CPU implementation (Local Process Pool): 

from fastapi import FastAPI
import concurrent.futures
import numpy as np
import asyncio
 
app = FastAPI()
executor = concurrent.futures.ProcessPoolExecutor(max_workers=4)
 
def heavy_numpy_task(data_array):
    # Pure CPU calculation running in a separate OS process (bypassing GIL)
    return np.linalg.inv(data_array).tolist()
 
@app.post("/api/v1/compute")
async def compute(payload: list[list[float]]):
    loop = asyncio.get_running_loop()
    data = np.array(payload)
    # Offloads CPU work to a local process pool, keeping the Event Loop non-blocking
    result = await loop.run_in_executor(executor, heavy_numpy_task, data)
    return {"result": result}

– Conclusion:
FastAPI faces the exact same physical bottleneck as Flask. While ProcessPoolExecutor prevents the Event Loop from freezing, it cannot overcome core saturation. Echoing Flask’s conclusion, the exact same architectural solution applies: heavy CPU processing must be decoupled from the API tier and offloaded to asynchronous background task queues.
Both frameworks require the same worker pattern to reliably process heavy CPU workloads at scale.

Pragmatic Engineering & Team Tradeoffs

– Pydantic CPU Overhead:
FastAPI enforces schema validation and serialization using Pydantic on every incoming and outgoing request.
On large JSON payloads, Pydantic’s CPU validation overhead can make pure REST endpoints slower than raw Flask dict responses.

– Developer Experience and Risk Profile:
– Flask (WSGI): Safe for mid/junior development teams. Code is sequential and linear. If a developer writes bad or blocking code, only their current thread is impacted.
– FastAPI (ASGI): High risk with inexperienced teams. A single blocking call (e.g., standard requests.get() or time.sleep()) hidden inside an async def route freezes the entire server Event Loop.

– Decision Matrix:

  • Choose Flask if: You are building standard REST APIs, CRUD applications, server-rendered apps, or working with a team unfamiliar with asyncio primitives.
  • Choose FastAPI if: You require real-time WebSockets, Server-Sent Events, heavy external microservice aggregation via asyncio.gather, or native OpenAPI/Pydantic typing workflows.
  • Use Worker Queues (Celery / RQ / Airflow) on both if: Endpoint execution involves heavy CPU operations, NumPy/ML workloads, or long-running background jobs.
Ce contenu a été publié dans Non classé. Vous pouvez le mettre en favoris avec ce permalien.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *