bigywater.tech
Flask · 166

Worker Timeout

worker 被 --timeout 杀掉之后会发生什么?对其他请求有多大影响?--preload 有什么用?--timeout 0 安全吗?这篇用真实的 gunicorn 与持续的请求流把答案量出来。

4149 → 2623 ms
单 worker 被杀后 /fast 的最大延迟:不加 --preload 与加 --preload(导入要 1.5 秒)
失败 0
2 个 worker 时一个被杀,/fast 失败的请求数
WORKER TIMEOUT
被杀的 worker 在 gunicorn 日志里的标志

2 个 worker

实测 · 本机执行输出
  2 个 worker,不加 --preload              /fast 331 个请求:失败 0,p99 6 ms,最大 12 ms | 慢请求:500 用 2575 ms | WORKER TIMEOUT 1 次,worker 启动 3 次
  2 个 worker,--preload                 /fast 331 个请求:失败 0,p99 5 ms,最大 12 ms | 慢请求:500 用 2624 ms | WORKER TIMEOUT 1 次,worker 启动 3 次

上一篇:Gunicorn Worker 数量;下一篇:连接池大小。

第 147 篇看过 --timeout 在各种 worker 类型下的行为,这一篇看 worker 被杀之后对其他请求的影响。

只有 1 个 worker

实测 · 本机执行输出
  1 个 worker,不加 --preload(导入 1.5 秒)    /fast 186 个请求:失败 0,p99 4145 ms,最大 4149 ms | 慢请求:500 用 2560 ms | WORKER TIMEOUT 1 次,worker 启动 2 次
  1 个 worker,--preload                 /fast 242 个请求:失败 0,p99 14 ms,最大 2623 ms | 慢请求:500 用 2598 ms | WORKER TIMEOUT 1 次,worker 启动 2 次
  1 个 worker,导入很快                      /fast 240 个请求:失败 0,p99 10 ms,最大 3040 ms | 慢请求:500 用 3000 ms | WORKER TIMEOUT 1 次,worker 启动 2 次

应用导入用 time.sleep 模拟重型依赖的加载时间。

--timeout 0

实测 · 本机执行输出
  --timeout 0,慢请求 4 秒:200,用 4014 ms,日志里 WORKER TIMEOUT 0 次

分步演示

Worker Timeout
本步的对象

    本文用到的工具与边界

    • 本机 macOS 27 arm64 / Python 3.14.7 / Flask 3.1.3 / Werkzeug 3.1.9 / Jinja2 3.1.6 / SQLAlchemy 2.1.1 / gunicorn 26.2.0(都装在自己的虚拟环境里);大多数实验用 Flask 的 test_client(直接调用 WSGI 应用,不经过网络),需要真实 HTTP 时另起 gunicorn 或开发服务器(端口 9600 以上,本机 127.0.0.1);计时用 time.perf_counter,数字每次运行会有小幅抖动。gunicorn sync worker
    • 没有验证:gthread 与 gevent 下的行为(第 147 篇看过 --timeout 对它们不生效)、--max-requests 的自动重启与抖动参数、容器编排对健康检查失败的重启叠加、preload 与数据库连接在 fork 后的问题(第 145 篇提到)
    京ICP备2026067502号-1京公网安备11010502063487号