Channels: Is it OK to use "python manage.py runserver" in production?

[oTree-org]

(Not a bug, just a general question.)

With channels, it looks like manage.py runserver is mostly a wrapper around Daphne, so is it OK to use runserver in production instead of calling daphne directly? I maintain a Django-based framework that now uses channels, and it seems that there are some potential advantages to instructing my users to use runserver:

• They can use the same command in development and production, don't have to remember to use a different one
• Django users are already familiar with runserver
• manage.py loads the Django settings automatically, so no need to pass the channel layer as an arg on the command line
• From my testing, daphne seems to be very light on CPU and RAM, so it seems reasonable to run workers in the same process, as runserver does by default with the 4 worker threads. On Heroku this would also allow us to run it all on 1 dyno.

Does this sound OK?

(By the way another difference I see from daphne is that runserver reloads when code changes.)

Also curious about anyone's findings regarding how to optimize server performance. Like how many workers you are running, whether you run them in processes vs threads, etc.

[andrewgodwin]

I would still suggest not, as runserver does not run things quite the same as a separate Daphne - in particular, it is not as efficient as a standalone one as it runs in a thread alongside the workers and they compete for CPU time inside a single process.

On Heroku, maybe it's worth the dyno reduction for a very small site, but I would not want to encourage it without some serious testing. It's also very inflexible and doesn't let you adjust the interfaces:workers ratio, which is how you can tune performance (based on if your site has a high number of open connections versus a high number of requests per second)

Turning off autoreload in such a suggestion with the command-line flag would be very sensible no matter what, as the reload code is a bit weird and I'd rather not have it wrapped round a production server.