Django 3中ASGI与WSGI模式请求处理的差异及高效性实现原理

Great question! Let’s break down the differences between ASGI and WSGI in Django 3, and why ASGI brings better efficiency to request handling.

ASGI vs WSGI: Core Differences in Request Handling #

• Protocol Support: WSGI is a synchronous standard built exclusively for HTTP/1.1, limiting it to traditional non-real-time HTTP requests. ASGI, by contrast, supports HTTP/1.1, HTTP/2, WebSockets, and other asynchronous protocols—this opens the door to building real-time features like chat apps, live notifications, or collaborative editing tools that WSGI can’t natively handle.
• Request Processing Model: WSGI uses a synchronous blocking model. Each request ties up a thread (or process, depending on your server setup) for its entire lifecycle. If the request hits an IO-bound operation (like a database query or external API call), that thread sits idle waiting for the IO to finish, wasting resources. ASGI supports both synchronous and asynchronous processing: with async views using async/await, when an IO operation is encountered, the request is paused, and the thread is freed up to handle other ready requests. Once the IO completes, the request resumes processing right where it left off.
• Server Compatibility: WSGI works with established servers like Gunicorn or uWSGI. ASGI requires ASGI-compliant servers such as Daphne (built by the Django team) or Uvicorn. Many modern servers now support both standards, making the transition from WSGI to ASGI smoother.

Why ASGI is More Efficient #

Your hunch is spot-on—this efficiency largely stems from how ASGI handles IO-bound requests. Here’s the detailed breakdown:

• Non-blocking Async IO Scheduling: In most web apps, the majority of request time is spent waiting on IO operations (database queries, cache lookups, external API calls). With ASGI’s asynchronous model, when a request hits an awaitable IO task, the event loop pauses that request and reuses the thread to process another request that’s ready to run. This means a single thread can manage multiple concurrent requests that are in a waiting state, instead of each request hogging a thread while idle. This drastically boosts the number of requests your server can handle per unit time.
• Optimized for Modern Protocols: ASGI has native support for HTTP/2, which allows multiple requests to be sent over a single TCP connection. This cuts down on the overhead of repeated TCP handshakes, especially for sites with lots of static assets or frequent small requests.
• Flexible Hybrid Model: You don’t have to rewrite all your existing Django code to use ASGI. It supports both async and sync views seamlessly: sync views are handled in a thread pool, while async views run directly on the event loop. This lets you adopt async incrementally, getting efficiency gains where it matters most (like IO-heavy views) without disrupting your existing codebase.

内容的提问来源于stack exchange，提问作者eskaes