Use gunicorn in the Docker image? Uvicorn not advised in prod

[jeffchuber]

https://fastapi.tiangolo.com/deployment/server-workers/

https://fastapi.tiangolo.com/deployment/server-workers/
https://fastapi.tiangolo.com/deployment/docker/#official-docker-image-with-gunicorn-uvicorn

Would need to think about how this would affect things being in-memory and making sure those could be shared.

[levand]

The main difference between Gunicorn and Uvicorn (as I understand it) is that Uvicorn is best as a single-worker model whereas Gunicorn has better performance and support for multiple workers, where each worker is its own python process.

So on a "traditional" server where you want parallel request processing by multiple isolated workers, Gunicorn or a Gunicorn+Uvicorn combo is going to perform better.

But if we're contemplating an MVP where the primary "hot" representation of the data is in-memory, then we can't have multiple workers, because multiple processes don't share memory. We'd end up with N diverging in-memory representations if we did that.

So Gunicorn only becomes relevant in a world where we have a "stateless" FastAPI server that's writing through each request to some shared-state persisted database incrementally. Which relates to the question you asked in #38 and does somewhat depend on the capabilities of DuckDB to support overlapping updates from multiple processes.

[jeffchuber]

Close relation to #38 - definitely agree.

[jeffchuber]

We could move forward with this now I believe. @levand

[jeffchuber]

Moving to backlog