Use Gunicorn on Heroku instead of runserver

[natea]

https://devcenter.heroku.com/articles/django#using-a-different-wsgi-server

[briandant]

Mezzanine threw a bit of a curveball with the deploy/gunicorn.conf.py file, so I'll have to look into that before I move forward with this. It's a bit different than the way I've done it in the past.

[natea]

This answer on Stackoverflow suggests putting this in the Procfile: http://stackoverflow.com/a/12862684

web: python manage.py run_gunicorn -b 0.0.0.0:\$PORT -w 9 -k gevent --max-requests 250 --preload

And this blog post (https://mike.tig.as/blog/2012/02/13/deploying-django-on-heroku/) recommends doing it this way:

# Unlike the gunicorn defined in Heroku's Django example, we're going
# to use one of the async worker classes, "gevent". Using an async worker class
# is recommended when serving traffic directly to gunicorn (which is what
# happens under the Heroku Cedar stack).
web: gunicorn_django -b 0.0.0.0:\$PORT -w 9 -k gevent --max-requests 250 --preload src/$PYTHON_APP_NAME/settings.py"

The only difference is that the first one uses manage.py run_gunicorn and the second one uses gunicorn_django. Not sure which is better/preferred.

[briandant]

Another example Gunicorn setup: https://github.com/BrianHicks/funding/blob/master/gunicorn.py.ini

"""gunicorn WSGI server configuration."""

from multiprocessing import cpu_count
from os import environ

def max_workers():
    return cpu_count()

bind = '0.0.0.0:' + environ.get('PORT', '8000')
max_requests = 1000
worker_class = 'gevent'
workers = max_workers()

And his wsgi.py: https://github.com/BrianHicks/funding/blob/master/wsgi.py

The Procfile has different stuff too: web: newrelic-admin run-program gunicorn -c gunicorn.py.ini wsgi:application

[natea]

yeah, there seems to be more than one way to skin a cat when it comes to configuring gunicorn on Heroku. ;) it would be nice if Heroku would actually document the best practices in their doc center.

On Sun, Feb 10, 2013 at 1:17 PM, Brian Dant notifications@github.comwrote:

Another example Gunicorn setup: https://github.com/BrianHicks/funding/blob/master/gunicorn.py.ini

— Reply to this email directly or view it on GitHubhttps://github.com/CodeRaising/coderaising/issues/2#issuecomment-13357952..

nate@appsembler.com +1 (617) 517-4953 http://twitter.com/natea | http://linkedin.com/in/natea

[briandant]

Went with web: python manage.py run_gunicorn -b 0.0.0.0:\$PORT -w 9 -k gevent --max-requests 250 --preload as the SO question was more recent

[briandant]

My earlier comment: "Mezzanine threw a bit of a curveball with the deploy/gunicorn.conf.py file, so I'll have to look into that before I move forward with this. It's a bit different than the way I've done it in the past."

Assuming that these files are only used if running Fabric, and by the looks of the settings file, we're not.

[vellamike]

Are you guys still working with web: python manage.py run_gunicorn -b 0.0.0.0:\$PORT -w 9 -k gevent --max-requests 250 --preload? How is your experience of doing that?

[briandant]

@vellamike: Yes, that's exactly what I'm using in production. Haven't had any problems yet, but I don't do any intense profiling or the like, so can't say much more than "seems good" :)