Note that there are some explanatory texts on larger screens.

plurals
  1. PODifference Between Gunicorn Worker Processes and Heroku Worker Dynos
    primarykey
    data
    text
    <p>I'm hoping the community can clarify something for me, and that others can benefit. </p> <p>My understanding is that gunicorn worker processes are essentially virtual replicas of Heroku web dynos. In other words, <em>Gunicorn's worker processes should not be confused with Heroku's worker processes</em> (e.g. Django Celery Tasks).</p> <p>This is because Gunicorn worker processes are focused on handling web requests (basically throttling up the performance of the Heroku Web Dyno) while Heroku Worker Dynos specialize in Remote API calls, etc that are long-running background tasks.</p> <p>I have a simple Django app that makes decent use of Remote APIs and I want to optimize the resource balance. I am also querying a PostgreSQL database on most requests. </p> <p>I know that this is very much an oversimplification, but am I thinking about things correctly?</p> <p><strong>Some relevant info:</strong></p> <p><a href="https://devcenter.heroku.com/articles/process-model" rel="nofollow noreferrer">https://devcenter.heroku.com/articles/process-model</a></p> <p><a href="https://devcenter.heroku.com/articles/background-jobs-queueing" rel="nofollow noreferrer">https://devcenter.heroku.com/articles/background-jobs-queueing</a></p> <p><a href="https://devcenter.heroku.com/articles/django#running-a-worker" rel="nofollow noreferrer">https://devcenter.heroku.com/articles/django#running-a-worker</a></p> <p><a href="http://gunicorn.org/configure.html#workers" rel="nofollow noreferrer">http://gunicorn.org/configure.html#workers</a></p> <p><a href="http://v3.mike.tig.as/blog/2012/02/13/deploying-django-on-heroku/" rel="nofollow noreferrer">http://v3.mike.tig.as/blog/2012/02/13/deploying-django-on-heroku/</a></p> <p><a href="https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/gunicorn/" rel="nofollow noreferrer">https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/gunicorn/</a></p> <p><strong>Other Quasi-Related Helpful SO Questions for those researching this topic:</strong></p> <p><a href="https://stackoverflow.com/questions/10401513/troubleshooting-site-slowness-on-a-nginx-gunicorn-django-stack">Troubleshooting Site Slowness on a Nginx + Gunicorn + Django Stack</a></p> <p><a href="https://stackoverflow.com/questions/11713871/performance-degradation-for-django-with-gunicorn-deployed-into-heroku">Performance degradation for Django with Gunicorn deployed into Heroku</a></p> <p><a href="https://stackoverflow.com/questions/10527512/configuring-gunicorn-for-django-on-heroku">Configuring gunicorn for Django on Heroku</a></p> <p><a href="https://stackoverflow.com/questions/10401513/troubleshooting-site-slowness-on-a-nginx-gunicorn-django-stack">Troubleshooting Site Slowness on a Nginx + Gunicorn + Django Stack</a></p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COA dyno is more like a host and a gunicorn worker is a process running on that host. There is not a one to one correspondence as you could have more than one gunicorn worker process running on a single dyno. If looking to tune your application and stack, you might consider looking at New Relic. Since you get access to New Relic standard subscription level for free on Heroku, no harm trying it at least.
      singulars
    2. COThanks Graham, I am using New Relic and it's quite useful. My understanding is that a heroku dyno is a single thread, one process host, but that gunicorn is a process that can spawn workers to handle multiple web requests concurrently. That being said, I'm still looking for someone to confirm that a gunicorn worker is fundamentally different to a heroku worker dyno.
      singulars
    3. COWay back in time dynos for Ruby were a single threaded process. Not so now. You can actually run up multiple processes in a dyno using foreman and in case of gunicorn, you could tell it to run three worker processes for handling requests. Technically I could (and am working on it), run up Apache/mod_wsgi in a dyno and have multiple processes which are all multithreaded handling requests.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload