我希望社区可以为我澄清一些事情，而其他人可以从中受益。
我的理解是，gunicorn工作流程本质上是Heroku web dynos的虚拟副本。换句话说， Gunicorn的工作流程不应该与Heroku的工作流程混淆（例如Django Celery Tasks）。
这是因为Gunicorn工作流程专注于处理Web请求（基本上限制了Heroku Web Dyno的性能），而Heroku Worker Dynos专注于远程API调用等，这些都是长时间运行的后台任务。
我有一个简单的Django应用程序，可以很好地使用远程API，我希望优化资源平衡。我也在大多数请求中查询PostgreSQL数据库。
我知道这非常简单，但我是否正确地思考问题？
一些相关信息：
https://devcenter.heroku.com/articles/process-model
https://devcenter.heroku.com/articles/background-jobs-queueing
https://devcenter.heroku.com/articles/django#running-a-worker
http://gunicorn.org/configure.html#workers
http://v3.mike.tig.as/blog/2012/02/13/deploying-django-on-heroku/
https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/gunicorn/
研究此主题的其他准相关有用的SO问题：
Troubleshooting Site Slowness on a Nginx + Gunicorn + Django Stack
Performance degradation for Django with Gunicorn deployed into Heroku
Configuring gunicorn for Django on Heroku
Troubleshooting Site Slowness on a Nginx + Gunicorn + Django Stack
答案 0 :(得分：14)
为了提供答案并阻止人们搜索评论，dyno就像整个计算机一样。使用Procfile，您可以为每个dynos 一个命令运行，并且它会在该命令上运行，定期重新运行它以刷新它并在崩溃时重新运行它。你可以想象，浪费整个运行单线程网络服务器的计算机是非常浪费的，那就是Gunicorn的用武之地。
Gunicorn主线程除了充当代理服务器之外什么都不做，产生给定数量的应用程序副本（工作者），在它们之间分发HTTP请求。它利用了每个dyno实际上有多个核心的事实。正如有人提到的，您应该选择的工作人员数量取决于您的应用程序运行所需的内存量。
与Bob Spryn在上一篇评论中所说的相反，还有其他方法可以利用这种并行机会在同一个dyno上运行单独的服务器。最简单的方法是创建一个单独的子proc文件，并在Foreman之后运行来自主Procfile 的全部Python Honcho等效，these directions，。基本上，在这种情况下，您的单个dyno命令是一个管理多个单个命令的程序。这有点像给予精灵的一个愿望，并希望再有4个愿望。
这样做的好处是可以充分利用你的动力学能力。这种方法的缺点是，当你共享一个dyno时，你失去了独立扩展应用程序各个部分的能力。当您缩放dyno时，它会缩放您复用到它上面的所有内容，这可能是不可取的。您可能必须使用诊断程序来决定何时应将服务放在其专用的dyno上。