7

我希望社区可以为我澄清一些事情，并且其他人可以从中受益。

我的理解是 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 Stack 上的站点缓慢故障排除

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

在 Heroku 上为 Django 配置 gunicorn

Nginx + Gunicorn + Django Stack 上的站点缓慢故障排除

4

1 回答 1

16

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

Gunicorn 主线程只是充当代理服务器，生成给定数量的应用程序副本（工作者），在它们之间分发 HTTP 请求。它利用了每个测功机实际上具有多个核心的事实。正如有人提到的，您应该选择的工作人员数量取决于您的应用程序运行所需的内存量。

与 Bob Spryn 在上一条评论中所说的相反，还有其他方法可以利用这种并行性机会在同一个测功机上运行不同的服务器。最简单的方法是创建一个单独的子 procfile 并按照这些说明从您的主 Procfile运行全 Python Foreman等效项Honcho。本质上，在这种情况下，您的单个 dyno 命令是一个管理多个单个命令的程序。这有点像从精灵那里得到一个愿望，然后再许下 4 个愿望。

The advantage of this is you get to take full advantage of your dynos' capacity. The disadvantage of this approach is that you lose the ability scale individual parts of your app independently when they're sharing a dyno. When you scale the dyno, it will scale everything you've multiplexed onto it, which may not be desired. You will probably have to use diagnostics to decide when a service should be put on its own dedicated dyno.

于 2013-04-11T17:00:20.117 回答