STAC API and Tiler not using gunicorn worker and worker configuration about planetary-computer-apis HOT 4 OPEN

For example,

instead of

uvicorn pctiler.main:app --host ${APP_HOST} --port ${APP_PORT} --log-level info

You would use something like

gunicorn pctiler.main:app --workers 4 --threads 4 --worker-class uvicorn.workers.UvicornWorker --bind ${APP_HOST}:${APP_PORT} --log-level info

from planetary-computer-apis.

Thanks @tonybaloney

so in https://fastapi.tiangolo.com/deployment/server-workers/ it specifically says:

In particular, when running on Kubernetes you will probably not want to use Gunicorn and instead run a single Uvicorn process per container, but I'll tell you about it later in that chapter.

I think for Stac API we could relaxe this but for the tiler maybe not because it's really CPU intensive (and not really async)

from planetary-computer-apis.

Ok that makes sense for the tiler.

For the STAC API, it depends on the concurrency potential of the requests and how Kubernetes is configured to scale-out the workers.

from planetary-computer-apis.

Thanks @tonybaloney - we've been considering reverting back to GUnicorn for our STAC API to evaluate the impact on some behaviors we've been seeing with requests. In general, concurrency potential of those requests should be high. We'll want to do some benchmarking, but we appreciate the observations.

from planetary-computer-apis.