4 ms·

Django without gunicorn? I’ll give it a go…

by RantyDave 2y ago

move-on-by 2y ago
I’ve largely enjoyed gunicorn. What do you dislike about it?
- DataDive 2y ago
  I largely agree here that of all the components in a stack, unicorn seems to be the least troublesome and almost invisible. I have never had a problem that I would have traced back to gunicorn not working ... On the other hand not having to run gunicorn as another separate service might be an advantage.
- RantyDave 2y ago
  Oh nothing really, it's just another cog is all. I'm running nginx because there's some things I want to serve statically (and it does a couple of other boring tasks really well too), so if I could just point it at the environment and tell it to go for it then it would just be a bit less messing around. I'm connecting nginx to gunicorn through a unix socket too and found that to be a bit of a pain.
anentropic 2y ago
I'm wondering what are the pros and cons of that vs this Years ago every website needed Apache or Nginx, then lately I've hardly used it at all... usually have a container with gunicorn behind a load balancer that is part of the cloud platform It's easy to see how to get Nginx Unit working, but not sure exactly how it fits into the utility picture vs other options
- teitoklien 2y ago
  Nginx is a reverse proxy, it can work as the load balancer, the static asset server, a response caching server, an authorization server, HLS streaming server, etc. Nginx has a lot of usecases in one package, most larger companies and more technical workplaces, use Nginx or similar alternatives. Nginx Unit typically is meant for unifying the entire application space of multiple programming languages served by 1 Server (which also acts as a static server) So serving golang, python, php code and application all under 1 single wsgi/asgi application server called nginx unit and be able to dynamically change its routes with api calls too. This allows you to have 1 root process in a docker container to control your python fastapi or golang api processes, without needing 1 container for nginx and 1 container for Python/Golang process or a supervisord like init system controlling 2 or more processes inside 1 container Everything is under nginx unit and nginx unit is being triggered as the main process inside the container. Moreover it is also much much much more faster in terms of response time than most language dependent application servers like gunicorn/unicorn for python3, etc [1] [1](https://medium.com/@le_moment_it/nginx-unit-discover-and-benchmark-part-3-c38661194cd0 https://medium.com/@le_moment_it/nginx-unit-discover-and-ben...)
- attentive 2y ago
  unit replaces gunicorn. It should also be much faster but you do your tests.
e-brake 2y ago
I am using NGINX Unit with Django in a bunch of production workloads, with high traffic. Works really well! The most time spent was building from source in Docker for ARM support and going down a rabbit hole of targeting the minor Python version that apt was installing on some Debians, w/o a virtual env, instead of the one it defaulted to. I'm a fan. High performance, easily configurable ASGI server for so many flavors.

Django without gunicorn? I’ll give it a go…

move-on-by 2y ago

I’ve largely enjoyed gunicorn. What do you dislike about it?

DataDive 2y ago
I largely agree here that of all the components in a stack, unicorn seems to be the least troublesome and almost invisible. I have never had a problem that I would have traced back to gunicorn not working ... On the other hand not having to run gunicorn as another separate service might be an advantage.
RantyDave 2y ago
Oh nothing really, it's just another cog is all. I'm running nginx because there's some things I want to serve statically (and it does a couple of other boring tasks really well too), so if I could just point it at the environment and tell it to go for it then it would just be a bit less messing around. I'm connecting nginx to gunicorn through a unix socket too and found that to be a bit of a pain.

anentropic 2y ago

I'm wondering what are the pros and cons of that vs this Years ago every website needed Apache or Nginx, then lately I've hardly used it at all... usually have a container with gunicorn behind a load balancer that is part of the cloud platform It's easy to see how to get Nginx Unit working, but not sure exactly how it fits into the utility picture vs other options

teitoklien 2y ago
Nginx is a reverse proxy, it can work as the load balancer, the static asset server, a response caching server, an authorization server, HLS streaming server, etc. Nginx has a lot of usecases in one package, most larger companies and more technical workplaces, use Nginx or similar alternatives. Nginx Unit typically is meant for unifying the entire application space of multiple programming languages served by 1 Server (which also acts as a static server) So serving golang, python, php code and application all under 1 single wsgi/asgi application server called nginx unit and be able to dynamically change its routes with api calls too. This allows you to have 1 root process in a docker container to control your python fastapi or golang api processes, without needing 1 container for nginx and 1 container for Python/Golang process or a supervisord like init system controlling 2 or more processes inside 1 container Everything is under nginx unit and nginx unit is being triggered as the main process inside the container. Moreover it is also much much much more faster in terms of response time than most language dependent application servers like gunicorn/unicorn for python3, etc [1] [1](https://medium.com/@le_moment_it/nginx-unit-discover-and-benchmark-part-3-c38661194cd0 https://medium.com/@le_moment_it/nginx-unit-discover-and-ben...)
attentive 2y ago
unit replaces gunicorn. It should also be much faster but you do your tests.

e-brake 2y ago

I am using NGINX Unit with Django in a bunch of production workloads, with high traffic. Works really well! The most time spent was building from source in Docker for ARM support and going down a rabbit hole of targeting the minor Python version that apt was installing on some Debians, w/o a virtual env, instead of the one it defaulted to. I'm a fan. High performance, easily configurable ASGI server for so many flavors.