FastAPI 使用 gunicorn 启动 uvicorn 工作者,如https://www.uvicorn.org/settings/中所述
但是 gunicorn 不允许使用自定义设置启动 uvicorn,如https://github.com/encode/uvicorn/issues/343中所述
该问题建议覆盖源文件中的 config_kwargs,例如https://github.com/encode/uvicorn/blob/master/uvicorn/workers.py
我们尝试过,但 uvicorn 不limit_concurrency
支持源中多个 uvicorn 文件中的设置:
https://github.com/encode/uvicorn/blob/master/uvicorn/workers.py
# fail
config_kwargs = {
"app": None,
"log_config": None,
"timeout_keep_alive": self.cfg.keepalive,
"timeout_notify": self.timeout,
"callback_notify": self.callback_notify,
"limit_max_requests": self.max_requests, "limit_concurrency": 10000,
"forwarded_allow_ips": self.cfg.forwarded_allow_ips,
}
https://github.com/encode/uvicorn/blob/master/uvicorn/main.py
# fail
kwargs = {
"app": app,
"host": host,
"port": port,
"uds": uds,
"fd": fd,
"loop": loop,
"http": http,
"ws": ws,
"lifespan": lifespan,
"env_file": env_file,
"log_config": LOGGING_CONFIG if log_config is None else log_config,
"log_level": log_level,
"access_log": access_log,
"interface": interface,
"debug": debug,
"reload": reload,
"reload_dirs": reload_dirs if reload_dirs else None,
"workers": workers,
"proxy_headers": proxy_headers,
"forwarded_allow_ips": forwarded_allow_ips,
"root_path": root_path,
"limit_concurrency": 10000,
"backlog": backlog,
"limit_max_requests": limit_max_requests,
"timeout_keep_alive": timeout_keep_alive,
"ssl_keyfile": ssl_keyfile,
"ssl_certfile": ssl_certfile,
"ssl_version": ssl_version,
"ssl_cert_reqs": ssl_cert_reqs,
"ssl_ca_certs": ssl_ca_certs,
"ssl_ciphers": ssl_ciphers,
"headers": list([header.split(":") for header in headers]),
"use_colors": use_colors,
}
uvicorn怎么能被迫尊重这个设置?我们仍然从 FastAPI 收到 503 错误
-------UPDATE------------ gunicorn 设置--worker-connections 1000
在发出 100 个并行请求时仍会导致 503,这些请求分发给许多工作人员。
但是,我认为这是一个更复杂的问题:我们的 API 端点做了很多繁重的工作,通常需要 5 秒才能完成。
2核2工人压力测试:
- A. 100+ 并发请求,端点重负载 --worker-connections 1
- B. 100+ 并发请求,端点重负载 --worker-connections 1000
- C. 100+ 并发请求,端点低负载 --worker-connections 1
- D. 100+ 并发请求,端点低负载 --worker-connections 1000
两个实验 A 和 B 都产生了 503 响应,因此假设 worker-connections 设置确实有效,太多的模拟连接似乎不会导致我们的 503 错误。
我们对这种行为感到困惑,因为我们期望 gunicorn/uvicorn 将工作排队,而不是抛出 503 错误。