之前为了实现 docker 部署，我把 Nginx 打包进了 DjangoStarter 的 compose 配置里了，不过这带来了配置的复杂度，特别是还要搭配框架实现 URL prefix 之类的功能。
从 v3.2.x 版本开始，我就启动了减法计划，简化代码和功能，减少心智负担，这个 Nginx 容器也是我一直想去掉的。
最近发现 Granian 这个 Rust 开发的 ASGI 服务器，性能高，而且还可以支持静态文件，正好完美符合我的需求，于是这次正好拿来替换原本使用的 Daphne
Granian#
项目主页: https://github.com/emmett-framework/granian
Granian 是一款高性能 Python Web Server，支持 ASGI、WSGI、RSGI，基于 Rust 编写，启动速度快、并发能力强，非常适合 Django / FastAPI / Starlette。
官方描述为 “A Rust HTTP server for Python applications built on top of Hyper/Tokio”。
特点：
支持 ASGI 3、RSGI（Rust-Server-Gateway Interface）和 WSGI 接口。
支持 HTTP/1 和 HTTP/2（未来计划 HTTP/3）协议。
支持静态文件直出 (“Direct static files serving”)。
使用方式#
很简单，不需要修改代码，只需要修改启动命令。
目前搭配 DjangoStarter 使用的启动命令是这样的：
granian --interface asgi --host 0.0.0.0 --port 8000 --static-path-route /static --static-path-mount ./static-dist config.asgi:application
类似 uvicorn，这个 granian 也支持热重载，加个 --reload 参数就行了
性能测试#
本次用 wrk 进行性能测试
测试数据#
以下数据在腾讯云 2 cores CPU + 2G 内存的服务器上测得。
django 5.x + ninja + daphne
$ wrk -t4 -c200 -d30s http://127.0.0.1:9876/api/django-starter/monitoring/health
Running 30s test @ http://127.0.0.1:9876/api/django-starter/monitoring/health
4 threads and 200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.97s 0.00us 1.97s 100.00%
Req/Sec 38.55 55.33 343.00 90.23%
1343 requests in 30.04s, 760.03KB read
Socket errors: connect 0, read 0, write 0, timeout 1342
Requests/sec: 44.70
Transfer/sec: 25.30KB
django 5.x + ninja + granian
$ wrk -t4 -c200 -d30s http://127.0.0.1:9875/api/django-starter/monitoring/hea
lth
Running 30s test @ http://127.0.0.1:9875/api/django-starter/monitoring/health
4 threads and 200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.20s 93.05ms 1.72s 82.69%
Req/Sec 83.13 105.81 460.00 83.72%
4980 requests in 30.04s, 2.85MB read
Requests/sec: 165.76
Transfer/sec: 97.31KB
因为好奇，我还找到之前一个很老的项目，使用WSGI部署的进行对比。
以下数据在私有云的 4 cores CPU + 2G 内存服务器上测得。
因为是完全不同的服务器硬件，数据仅供参考。
Django 3.x + drf + uwsgi + nginx
$ wrk -t4 -c200 -d30s http://127.0.0.1:9001/api/health/
Running 30s test @ http://127.0.0.1:9001/api/health/
4 threads and 200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 295.30ms 373.95ms 1.96s 85.14%
Req/Sec 205.54 68.42 380.00 73.73%
19583 requests in 30.09s, 5.83MB read
Socket errors: connect 0, read 0, write 0, timeout 474
Non-2xx or 3xx responses: 12
Requests/sec: 650.89
Transfer/sec: 198.32KB
Django 3.x + ninja + uwsgi + nginx
$ wrk -t4 -c200 -d30s http://127.0.0.1:9001/api2/health
Running 30s test @ http://127.0.0.1:9001/api2/health
4 threads and 200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 203.75ms 280.30ms 1.95s 88.44%
Req/Sec 250.81 108.59 500.00 61.21%
22542 requests in 30.06s, 5.68MB read
Socket errors: connect 0, read 0, write 0, timeout 420
Non-2xx or 3xx responses: 12
Requests/sec: 749.88
Transfer/sec: 193.35KB
结论#
以下是使用 AI 对上面的测试数据进行分析的结论，不过 ASGI 和 uWSGI 不在同一台服务器进行测试，其实很难直接对比。目前看来切换到 Granian 确实可以提高4倍的性能。
① Daphne 在 Django + ASGI 下的性能表现非常差
延迟直接飙到 1.9 秒级别，
wrk 200 并发几乎把它压扁，
1343 请求里 1342 超时，等于完全顶不住。
说白了：Daphne 更像是开发环境服务器，不推荐上生产高并发。
② Granian 性能比 Daphne 好 3–4 倍，但仍然有限
每秒处理 165 req/s（同机房、同代码）。
延迟仍然在 1.2s 左右，远不算理想（在高并发下仍吃力）。
优点是 ASGI 原生 + Rust 实现，比 Daphne 强太多。
直观感受：Granian 能用，但你别指望它像 uWSGI 那样扛流量。
③ uWSGI（WSGI）表现碾压：单机可达 650–750 req/s 级别
性能直接是 granian 的 4～5 倍。
虽然是老架构（WSGI），但调优成熟、稳定、分配机制强，抗压能力远强于同类 ASGI 服务。
简而言之：如果不用异步，WSGI 依旧是 Django 的最强部署方式（性能层面）。
docker-compose#
这是精简后的 compose 配置
services:
app:
image: ${APP_IMAGE_NAME}:${APP_IMAGE_TAG}
container_name: $APP_NAME-app
command:
- granian
- --interface
- asgi
- --host
- 0.0.0.0
- --port
- "${APP_INTERNAL_PORT:-8000}"
- --static-path-route
- /static
- --static-path-mount
- /project/static-dist
- config.asgi:application
命令行参数#
它的命令行结构很简单：
granian [OPTIONS] APP
其中：
APP 是入口，例如：config.asgi:application
OPTIONS 是各种配置参数
下面按分类整理所有参数（附带说明与建议）。
🧩 基础参数（启动必要项）#
参数 说明 默认值
APP 要启动的应用入口（如 mysite.asgi:application） 必填
--interface 接口类型：asgi / asginl / rsgi / wsgi rsgi
--host 监听地址 127.0.0.1
--port 端口 8000
--uds 使用 Unix Domain Socket 无
--http HTTP 版本：1、2、auto auto
--workers Worker 进程数 1
👉 Django、FastAPI 用户一般写：
--interface asgi
🗂️ 静态文件服务（Django 专用配置）#
Granian 内置静态文件服务：
参数 说明 默认值
--static-path-route URL 路由前缀，例如 /static /static
--static-path-mount 文件目录，例如 /project/static-dist 无
--static-path-expires 缓存时间（秒） 86400
示例：
--static-path-route /static --static-path-mount /project/static-dist
⚙️ 多进程、线程、事件循环选项#
Worker / Thread
参数 说明
--workers Worker 数量
--blocking-threads 阻塞线程数
--runtime-threads Runtime 线程数
--runtime-blocking-threads Runtime I/O 阻塞线程
建议：
CPU × 2 左右的 worker 容量通常够用
大部分 ASGI 项目不需要调 thread 参数
🔁 事件循环 & Runtime#
参数 说明
--loop 事件循环：auto、asyncio、rloop、uvloop
--task-impl task 执行器：asyncio / rust
--runtime-mode 单线程 st / 多线程 mt
适用建议：
普通项目：用默认即可
高并发：--task-impl rust 性能更强
🔒 HTTP/1 与 HTTP/2 相关参数#
类别 常用配置
HTTP/1 --http1-buffer-size、--http1-keep-alive
HTTP/2 --http2-* 一系列参数控制 flow control、窗口、keepalive、stream 数量等
大部分项目无需调整，默认即可。
📜 日志（Logging）#
参数 说明 默认
--log / --no-log 启用日志 enabled
--log-level 日志等级 info
--log-config 使用 JSON 配置文件 无
--access-log 开启 access log disabled
--access-log-fmt Access log 格式 无
如果你希望生产环境有 Nginx 样式的 access log：
--access-log --access-log-fmt "%a %r %s %b"
🔁 热重载（开发环境用）#
参数 说明
--reload 开启自动重载
--reload-paths 指定监控目录
--reload-ignore-* 忽略目录、路径、pattern
例如：
--reload --reload-paths src/
🔐 HTTPS#
参数 说明
--ssl-certificate 证书文件
--ssl-keyfile 密钥文件
--ssl-ca CA
--ssl-client-verify 客户端证书验证
（一般反向代理交给 Nginx 做 HTTPS）
🧰 其他有用但不常改的参数#
参数 说明
--working-dir 切换 WorkDir
--env-files 加载环境变量文件
--factory APP 是 factory function 时使用
--url-path-prefix 应用挂载前缀
--process-name 自定义进程名
--pid-file 写入 PID 文件
--version 显示版本
--help 显示帮助
