Workers parameter is ignored when starting server from Config

[fedem96]

The following works as expected (it creates 4 workers):

import uvicorn
from fastapi import FastAPI, Response

if __name__ == "__main__":
    uvicorn.run(
        "main:app",
        host="0.0.0.0",
        port=8123,
        workers=4,
    )


app = FastAPI()


@app.get("/")
async def ack() -> Response:
    """Health check."""
    return Response(status_code=200)

while the following doesn't (it's ignoring the workers parameter):

import uvicorn
from fastapi import FastAPI, Response

if __name__ == "__main__":
    config = uvicorn.Config(
        "main:app",
        host="0.0.0.0",
        port=8123,
        workers=4,
    )
    uvicorn.Server(config).run()


app = FastAPI()


@app.get("/")
async def ack() -> Response:
    """Health check."""
    return Response(status_code=200)

tested on Python 3.10.13 with:

fastapi==0.108.0
uvicorn==0.25.0

[Kludex]

Correct.

[fedem96]

So, should I open an issue?

[Kludex]

Maybe a warning can be raised if user uses uvicorn.Config directly with workers>1, but it's not a bug. It's intended.

[fedem96]

No idea why should be different, so I'll just use uvicorn.run.

The unintuitive thing is that workers seems to be already checked by uvicorn.Config.
If you pass reload=True with workers>1, you get the warning WARNING: "workers" flag is ignored when reloading is enabled., but so "workers" is still ignored also with reload=False.

Having at least a warning that say that "workers" is always ignored (and suggest to use uvicorn.run as alternative) would be helpful.

[senese]

Actually saying just "Correct" doesn't help anyone. It would be beneficial for everyone if you'd tell us why this is intended cause the documentation isn't clear with this scenario.

[SaadKaleem]

Faced with this issue, why is this intended the way it is?

What is stopping me from forking multiple processes to start multiple uvicorn processes, at least to circumvent python's GIL for better parallelization on CPU-bound tasks? I imagine stateful params like ws_max_queue / limit_concurrency are not synchronized in a process-safe anyway?

I imagine that's what process managers are for, though.