Your question interested me so I went looking. The page you link to further links to the uvicorn documentation which seems to indicate their suggestion for production deployments is to use gunicorn and the uvicorn worker.
Their rationale seems to be that uvicorn is great at running an event loop and operating asynchronously but the worker process management including increasing and decreasing them and hitless upgrades were managed by gunicorns more mature features here.
The way I am conceptualising the core benefit here is multi core machines where workers can be thrown into different process threads to utilise all available cores while the asynchronous benefits improve parallelisation of requests where applied to reduce time to run particular views to completion. So they work together for best effect.
https://www.uvicorn.org/#running-with-gunicorn
Regards
Alexander
Alexander Neilson
Neilson Productions Limited
021 329 681
alexander@neilson.net.nz
On 6/06/2022, at 16:06, Dan Davis <dansmood@gmail.com> wrote:
I am doing some work comparing various ASGI frameworks, SQL Alchemy, just writing the SQL, and that sort of thing, in order to determine what I think. Speed isn't every thing, but speed is a thing.Anyway, I was reading about this at https://docs.djangoproject.com/en/4.0/howto/deployment/asgi/uvicorn/ and it is curious that the advise is to run uvicorn as a work rather than a full ASGI server. Can someone explain why this is necessary or better?Thanks,-Dan--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/5dbf8350-1c28-4eb1-a3c8-f3a06566a06dn%40googlegroups.com.
No comments:
Post a Comment