Gunicorn工人流程与Heroku工作者Dynos的区别

Question

我希望社区可以为我澄清一些事情,其他人可以从中受益.

我的理解是,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问题:

排除Nginx + Gunicorn + Django堆栈上的站点缓慢

将Gunicorn部署到Heroku中的Django性能下降

在Heroku上为Django配置gunicorn

排除Nginx + Gunicorn + Django堆栈上的站点缓慢

Answer 1

为了提供答案并防止人们不得不搜索评论,dyno就像整个计算机.使用Procfile,你可以为每个dynos提供一个命令来运行,它会自动运行该命令,定期重新运行它以刷新它并在崩溃时重新运行它.可以想象,浪费整个运行单线程网络服务器的计算机是相当浪费的,这就是Gunicorn的用武之地.

Gunicorn主线程除了充当代理服务器之外什么都不做,产生给定数量的应用程序副本(工作者),在它们之间分发HTTP请求.它利用了每个dyno实际上有多个核心的事实.正如有人提到的,您应该选择的工作人员数量取决于您的应用程序运行所需的内存量.

与Bob Spryn在上一篇评论中所说的相反,还有其他方法可以利用这种并行机会在同一个dyno上运行单独的服务器.最简单的方法是让一个独立的子procfile并运行所有的Python 工头等同,本町,从你的主要Procfile,以下这些方向.基本上,在这种情况下,您的单个dyno命令是一个管理多个单个命令的程序.这有点像给予精灵的一个愿望,并希望能有4个愿望.

这样做的好处是你可以充分利用你的动力学能力.这种方法的缺点是,当你共享一个dyno时,你失去了独立扩展应用程序各个部分的能力.当您缩放dyno时,它会缩放您复用到它上面的所有内容,这可能是不可取的.您可能必须使用诊断程序来决定何时将服务放在自己的专用dyno上.