Connection lifecycle management in FastAPI - Performance & Optimization

Performance: Connection lifecycle management

HIGH IMPACT

This concept affects how efficiently the server handles client connections, impacting request latency and server resource usage.

Handling HTTP connections in FastAPI

FastAPI

from fastapi import FastAPI
from fastapi import Depends
app = FastAPI()

async def get_db():
    db = open_db_connection()
    try:
        yield db
    finally:
        db.close()

@app.get("/")
async def read_root(db=Depends(get_db)):
    data = db.query("SELECT * FROM table")
    return data

Using dependency injection with proper connection open/close ensures connections are reused or closed promptly.

📈 Performance GainReduces latency by 50-100ms per request, prevents resource leaks, and keeps server responsive under load.

Handling HTTP connections in FastAPI

FastAPI

from fastapi import FastAPI
app = FastAPI()

@app.get("/")
async def read_root():
    # Opening a new database connection per request without closing
    db = open_db_connection()
    data = db.query("SELECT * FROM table")
    return data

Opening a new connection on every request without closing or reusing causes high latency and resource leaks.

📉 Performance CostTriggers high CPU and memory usage, increases request latency by 50-100ms per connection, risks max connection limits.

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Opening new DB connection per request without closing	N/A	N/A	N/A	[X] Bad
Using dependency injection with connection close in finally block	N/A	N/A	N/A	[OK] Good
WebSocket without disconnect handling	N/A	N/A	N/A	[X] Bad
WebSocket with disconnect exception handling	N/A	N/A	N/A	[OK] Good

Rendering Pipeline

Connection lifecycle management affects the server's ability to accept, process, and close client connections efficiently, impacting request handling speed and resource usage.

→Request Handling

→Resource Allocation

→Connection Teardown

⚠️ BottleneckResource Allocation when connections are not properly closed or reused

Core Web Vital Affected

INP

This concept affects how efficiently the server handles client connections, impacting request latency and server resource usage.

Optimization Tips

1Always close or reuse connections to avoid resource leaks.

2Handle WebSocket disconnects to free server resources.

3Use FastAPI dependency injection to manage connection lifecycle cleanly.

Performance Quiz - 3 Questions

What is a key benefit of properly closing database connections in FastAPI endpoints?

A Reduces server resource usage and request latency

B Increases the number of open connections

C Makes the server slower but more stable

D Prevents the server from accepting new connections

DevTools: Network and Performance panels

How to check: Use the Network panel to monitor open connections and their duration. Use the Performance panel to record server response times and resource usage during load.

What to look for: Look for long-lived connections that never close and high latency in requests indicating poor connection management.

Practice

1. What is the main purpose of using yield in FastAPI dependencies for connection lifecycle management?

easy

A. To setup a resource before the request and clean it up after the request

B. To define a synchronous function only

C. To permanently keep a connection open for all requests

D. To return multiple values from a function

Solution

1. Step 1: Understand yield in dependencies

   In FastAPI, yield is used in dependencies to create a setup before the request and a cleanup after the request finishes.

2. Step 2: Identify the lifecycle role

   This pattern ensures resources like database connections open before and close after each request, preventing leaks.

3. Final Answer:

   To setup a resource before the request and clean it up after the request -> Option A

4. Quick Check:

   Yield in dependencies = setup and cleanup per request [OK]

Hint: Yield in dependencies means setup before and cleanup after request [OK]

Common Mistakes:

• Thinking yield returns multiple values at once
• Assuming yield keeps connection open forever
• Confusing yield with async context managers

2. Which of the following is the correct way to define a FastAPI dependency that opens a connection before a request and closes it after using yield?

easy

A. def get_conn():
conn = open_conn()
yield conn
return
conn.close()

B. def get_conn():
conn = open_conn()
return conn
conn.close()

C. async def get_conn():
conn = open_conn()
yield conn
conn.close()

D. def get_conn():
conn = open_conn()
yield conn
conn.close()

Solution

1. Step 1: Check the use of yield for setup and cleanup

   def get_conn(): conn = open_conn() yield conn conn.close() correctly uses yield to provide the connection and then closes it after the request.

2. Step 2: Identify syntax and flow correctness

   def get_conn(): conn = open_conn() return conn conn.close() returns before closing, so cleanup never runs. async def get_conn(): conn = open_conn() yield conn conn.close() mixes async with a sync open_conn (may cause issues). def get_conn(): conn = open_conn() yield conn return conn.close() returns early after yield, skipping cleanup.

3. Final Answer:

   def get_conn(): conn = open_conn() yield conn conn.close() -> Option D

4. Quick Check:

   Yield then cleanup = correct dependency pattern [OK]

Hint: Yield must be followed by cleanup code, not return [OK]

Common Mistakes:

• Placing return before cleanup code
• Using async without async resource
• Returning after yield instead of cleanup

3. Given this FastAPI dependency:

async def get_db():
    db = await connect_db()
    try:
        yield db
    finally:
        await db.disconnect()

What happens when a request finishes using this dependency?

medium

A. An error occurs because yield cannot be used with async

B. The database connection remains open for reuse

C. The database connection is closed asynchronously after the request

D. The connection is closed before the request starts

Solution

1. Step 1: Analyze async dependency with yield and finally

   The yield pauses the function to provide db during the request, then finally runs cleanup after the request.

2. Step 2: Understand async cleanup

   The await db.disconnect() runs after the request finishes, closing the connection asynchronously.

3. Final Answer:

   The database connection is closed asynchronously after the request -> Option C

4. Quick Check:

   Async yield with finally = async cleanup after request [OK]

Hint: Async yield with finally cleans up after request ends [OK]

Common Mistakes:

• Thinking yield can't be async
• Assuming connection stays open
• Confusing order of cleanup

4. Identify the error in this FastAPI startup event handler:

@app.on_event("startup")
@asynccontextmanager
async def startup():
    await connect_to_service()
    yield
    await disconnect_from_service()

medium

A. Missing async keyword before function definition

B. Cannot combine @app.on_event with @asynccontextmanager on the same function

C. Yield cannot be used in async functions

D. No error, this is correct usage

Solution

1. Step 1: Understand decorator usage for startup events

   The @app.on_event("startup") expects a normal async function, not an async context manager.

2. Step 2: Recognize conflict of decorators

   Using @asynccontextmanager with @app.on_event on the same function is invalid because FastAPI expects a coroutine, not a context manager.

3. Final Answer:

   Cannot combine @app.on_event with @asynccontextmanager on the same function -> Option B

4. Quick Check:

   @app.on_event and @asynccontextmanager cannot be combined [OK]

Hint: Don't mix @app.on_event with @asynccontextmanager on one function [OK]

Common Mistakes:

• Assuming yield is invalid in async functions
• Forgetting async keyword
• Thinking this pattern is valid

5. You want to manage a database connection pool that opens once when the FastAPI app starts and closes when it shuts down. Which is the best way to implement this lifecycle management?

hard

A. Use @app.on_event("startup") to open and @app.on_event("shutdown") to close the pool directly without context managers

B. Use a dependency with yield to open and close the pool per request

C. Open the pool globally outside FastAPI and never close it

D. Use @asynccontextmanager to create a context manager function and call it in @app.on_event("startup") and @app.on_event("shutdown")

Solution

1. Step 1: Understand app-wide resource lifecycle

   A connection pool should open once at app startup and close at shutdown, not per request.

2. Step 2: Choose correct FastAPI pattern

   Using @app.on_event("startup") and @app.on_event("shutdown") to open and close the pool directly is the simplest and recommended way.

3. Step 3: Why not others?

   Use @asynccontextmanager to create a context manager function and call it in @app.on_event("startup") and @app.on_event("shutdown") misuses @asynccontextmanager with events. Use a dependency with yield to open and close the pool per request opens/closes per request, which is inefficient. Open the pool globally outside FastAPI and never close it never closes, risking resource leaks.

4. Final Answer:

   Use @app.on_event("startup") to open and @app.on_event("shutdown") to close the pool directly without context managers -> Option A

5. Quick Check:

   App startup/shutdown events manage global resources best [OK]

Hint: Use startup and shutdown events for global resource management [OK]

Common Mistakes:

• Opening/closing pool per request wastes resources
• Not closing pool causes leaks
• Misusing asynccontextmanager for app events