[QUESTION] why using gunicorn? about cloudrun-fastapi HOT 4 CLOSED

@anthonycorletti I had the time to rethink this and I concluded that gunicorn is still a good choice for CloudRun after all (and other systems as well), as long as the user has the option to deploy on CloudRun with multiple CPUs (and he is not utilizing them for multi-process work inside the server), gunicorn can have a great impact on performance.
So I guess the number of workers really depends on the number of CPUs the revision deployed with.

from cloudrun-fastapi.

great question! sebastian makes a great point and i would suggest deploying your container in the best way that suits your use case. for something like cloud run i think the approach of using a single uvicorn worker is fine. you could also just run one gunicorn-uvicorn worker. there is no particularly rigorous reason why ive done it this way. ive been using fastapi for a few years now so i might be a bit stuck in my ways haha. ill see if i have time to make some changes. open to pull requests if you'd like to make one for uvicorn deployment support!

from cloudrun-fastapi.

@H3zi lmk what you think of https://github.com/anthonycorletti/cloudrun-fastapi/tree/docker/single-uvicorn-worker-per-container/ hope it helps!

The more I think about it I definitely think it depends on your applications. If you don't want to rely on thread management directly through fastapi alone, gunicorn+uvicorn would be good to use.

from cloudrun-fastapi.

sounds cool! ill close this out.

from cloudrun-fastapi.