6 ms·

it kinda has - we use gunicorn with fastapi using the uvicorn asgi workers https://fastapi.tiangolo.com/deployment/server-workers/ https://fastapi.tiangolo.com

it kinda has - we use gunicorn with fastapi using the uvicorn asgi workers https://fastapi.tiangolo.com/deployment/server-workers/ https://fastapi.tiangolo.com/deployment/server-workers/

qff 5y ago
Green threads (gunicorn/gevent) allows you to write Python the way you always have and gain many of the benefits of async. Uvicorn and ASGI do not. For those you need to handle async explictly.
- sandGorgon 5y ago
  i hear you - however the framework captures most of the abstraction entirely. In addition, most of the bottlenecks are actually i/o (db queries, etc) where its entirely worth doing it explicitly versus magic. in a general programming language sense...ur right. But from the POV of what gunicorn/fastapi are actually used for - web frameworks - its actually quite good.
ramraj07 5y ago
The list of terms in that sentence: Gunicorn Fastapi Uvicorn Asgi I suppose also nginx docker?
- dgellow 5y ago
  Edit: the grandparent comment has now been updated to clarify, so my comment here is not relevant anymore. ASGI is similar to WSGI but for async oriented web servers. The person you respond to is saying that they use Uvicorn via the ASGI interface. See https://asgi.readthedocs.io/en/latest/ https://asgi.readthedocs.io/en/latest/.
- orf 5y ago
  The list of letters in that sentence: a c d e f g h i k l m n o p r s t u v x I suppose also newlines?
floatrock 5y ago
I've always been a bit confused by this deployment model. gunicorn bills itself as "Gunicorn 'Green Unicorn' is a Python WSGI HTTP Server for UNIX. It's a pre-fork worker model." uvicorn's one-liner "Uvicorn is a lightning-fast ASGI server implementation, using uvloop and httptools." So it seems redundant at first to be running both, but what the gunicorn+uvicorn-worker-process pattern really does is throw away the "WSGI HTTP Server" part of gunicorn and just use the "pre-fork worker" process management part, with the underlying processes actually being ASGI. If you run in a different kind of process-management environment like k8s, does running gunicorn+uvicorn give you anything else?
- sandGorgon 5y ago
  Gunicorn fundamentally runs everything as a worker process. You have sync, gthread, gevent, evenlet, tornado (tornado was also a popular server). UvicornWorker is another type of gunicorn worker... incidentally authored by the same guys who built uvicorn. Nothing strange at all. But ur question is genuine - but it is orthogonal to the uvicorn part of this answer. Fundamentally, in a k8s model...why bother with gunicorn? The answer: I don't know. I do love the control that gunicorn gives me...so I'd probably use it even if I was using a single worker. However there is a complex answer with Threads vs cores vs pods that I'm unqualified to give.

it kinda has - we use gunicorn with fastapi using the uvicorn asgi workers https://fastapi.tiangolo.com/deployment/server-workers/ https://fastapi.tiangolo.com/deployment/server-workers/

qff 5y ago

Green threads (gunicorn/gevent) allows you to write Python the way you always have and gain many of the benefits of async. Uvicorn and ASGI do not. For those you need to handle async explictly.

sandGorgon 5y ago
i hear you - however the framework captures most of the abstraction entirely. In addition, most of the bottlenecks are actually i/o (db queries, etc) where its entirely worth doing it explicitly versus magic. in a general programming language sense...ur right. But from the POV of what gunicorn/fastapi are actually used for - web frameworks - its actually quite good.

ramraj07 5y ago

The list of terms in that sentence: Gunicorn Fastapi Uvicorn Asgi I suppose also nginx docker?

dgellow 5y ago
Edit: the grandparent comment has now been updated to clarify, so my comment here is not relevant anymore. ASGI is similar to WSGI but for async oriented web servers. The person you respond to is saying that they use Uvicorn via the ASGI interface. See https://asgi.readthedocs.io/en/latest/ https://asgi.readthedocs.io/en/latest/.
orf 5y ago
The list of letters in that sentence: a c d e f g h i k l m n o p r s t u v x I suppose also newlines?

floatrock 5y ago

I've always been a bit confused by this deployment model. gunicorn bills itself as "Gunicorn 'Green Unicorn' is a Python WSGI HTTP Server for UNIX. It's a pre-fork worker model." uvicorn's one-liner "Uvicorn is a lightning-fast ASGI server implementation, using uvloop and httptools." So it seems redundant at first to be running both, but what the gunicorn+uvicorn-worker-process pattern really does is throw away the "WSGI HTTP Server" part of gunicorn and just use the "pre-fork worker" process management part, with the underlying processes actually being ASGI. If you run in a different kind of process-management environment like k8s, does running gunicorn+uvicorn give you anything else?

sandGorgon 5y ago
Gunicorn fundamentally runs everything as a worker process. You have sync, gthread, gevent, evenlet, tornado (tornado was also a popular server). UvicornWorker is another type of gunicorn worker... incidentally authored by the same guys who built uvicorn. Nothing strange at all. But ur question is genuine - but it is orthogonal to the uvicorn part of this answer. Fundamentally, in a k8s model...why bother with gunicorn? The answer: I don't know. I do love the control that gunicorn gives me...so I'd probably use it even if I was using a single worker. However there is a complex answer with Threads vs cores vs pods that I'm unqualified to give.