Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it OK to use "python manage.py runserver" in production? #142

Closed
oTree-org opened this issue May 1, 2016 · 1 comment

Comments

Projects
None yet
2 participants
@oTree-org
Copy link

commented May 1, 2016

(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

This comment has been minimized.

Copy link
Member

commented May 1, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.