Claude
6bcf3b9ac9
Production entrypoint switch:
- pyproject.toml: add gunicorn>=23.0 dep
- gunicorn.conf.py: env-var-driven config (bind, workers, threads,
timeout, graceful_timeout, keepalive, log level, access-log format)
- Dockerfile: CMD gunicorn main:app (auto-loads gunicorn.conf.py from
WORKDIR /app)
- docker-compose.yml: forward GUNICORN_WORKERS / GUNICORN_TIMEOUT /
GUNICORN_BIND
- .env.example: document the new tunables
Why gunicorn over standalone uvicorn for production:
- Process supervision: master restarts crashed workers, restarts on
memory leaks
- Graceful shutdown: SIGTERM drains workers in-flight
- Multi-worker: concurrent requests actually run in parallel
- Standard ops: k8s readiness probes, log aggregators, etc. all know
gunicorn
Why uvicorn workers (not sync workers): gunicorn can't natively serve
ASGI; uvicorn.workers.UvicornWorker is the canonical way to run an
ASGI app under gunicorn.
Defaults:
- 2 workers (small MCP service; raise for high concurrency)
- 1 thread per worker (no blocking I/O)
- 120s timeout (yarn logs can be slow; uvicorn's 30s default is too
tight)
Verified: gunicorn boots, lifespan runs (14 tools logged), MCP
initialize + tools/list + tools/call all work, /openapi.json = 200,
multiple gunicorn worker processes visible in ps.
uv sync picked up gunicorn 26.0.0. Tests still 116/116.
25 lines
451 B
TOML
25 lines
451 B
TOML
[project]
|
|
name = "spark-executor-mcp"
|
|
version = "0.1.0"
|
|
requires-python = ">=3.12"
|
|
dependencies = [
|
|
"fastapi>=0.138.0",
|
|
"fastapi-mcp>=0.4.0",
|
|
"gunicorn>=23.0",
|
|
"httpx>=0.28.1",
|
|
"loguru>=0.7.3",
|
|
"pydantic>=2.13.4",
|
|
"pydantic-core>=2.46.4",
|
|
"uvicorn>=0.49.0",
|
|
]
|
|
|
|
[dependency-groups]
|
|
dev = [
|
|
"pytest>=8.0",
|
|
"pytest-mock>=3.14",
|
|
]
|
|
|
|
[[tool.uv.index]]
|
|
url = "https://pypi.tuna.tsinghua.edu.cn/simple/"
|
|
default = true
|