3 ms·

> use an async app server like uvicorn with async views instead of gunicorn I believe gunicorn with the uvicorn worker class is the recommended production serv

> use an async app server like uvicorn with async views instead of gunicorn I believe gunicorn with the uvicorn worker class is the recommended production server. > For production deployments we recommend using gunicorn with the uvicorn worker class. https://www.uvicorn.org/#running-with-gunicorn https://www.uvicorn.org/#running-with-gunicorn

nickjj 4y ago
> I believe gunicorn with the uvicorn worker class is the recommended production server. Yep for production that works. In development tho I don't think the gunicorn --reload flag works with that worker type. There is an issue open for this at https://github.com/benoitc/gunicorn/issues/2339 https://github.com/benoitc/gunicorn/issues/2339 and since I last tried about a year ago I guess they have an unofficial "workaround solution" in one of the comments but it involves making a custom class to support reloading but that requires copying in some code into your project and also using different worker types in dev vs prod. I think this is a good example of why I don't default to uvicorn and async in the project with Django 4.1. The whole package of "async everything" isn't ready for prime time in my opinion. It will improve over time but it's a waiting game at this point. Early adapters can easily swap it in if they want.
- collinmanderson 4y ago
  Interesting looks like it might actually be a python bug. Somehow just changing from sys.exit(0) -> os._exit(0) apparently fixes it. "There is a problem with using the sys.exit() in a forked process (child processes or workers) instead of using the os._exit() that is mentioned in python documentation." https://github.com/benoitc/gunicorn/pull/2820 https://github.com/benoitc/gunicorn/pull/2820 I've always just needed to manually reload the gunicorn async server in development. Super annoying.

nickjj 4y ago

> I believe gunicorn with the uvicorn worker class is the recommended production server. Yep for production that works. In development tho I don't think the gunicorn --reload flag works with that worker type. There is an issue open for this at https://github.com/benoitc/gunicorn/issues/2339 https://github.com/benoitc/gunicorn/issues/2339 and since I last tried about a year ago I guess they have an unofficial "workaround solution" in one of the comments but it involves making a custom class to support reloading but that requires copying in some code into your project and also using different worker types in dev vs prod. I think this is a good example of why I don't default to uvicorn and async in the project with Django 4.1. The whole package of "async everything" isn't ready for prime time in my opinion. It will improve over time but it's a waiting game at this point. Early adapters can easily swap it in if they want.

collinmanderson 4y ago
Interesting looks like it might actually be a python bug. Somehow just changing from sys.exit(0) -> os._exit(0) apparently fixes it. "There is a problem with using the sys.exit() in a forked process (child processes or workers) instead of using the os._exit() that is mentioned in python documentation." https://github.com/benoitc/gunicorn/pull/2820 https://github.com/benoitc/gunicorn/pull/2820 I've always just needed to manually reload the gunicorn async server in development. Super annoying.