Gunicorn Worker Processes和Heroku Worker Dynos之间的区别
Gunicorn Worker Processes和Heroku Worker Dynos之间的区别
我希望社区能为我澄清一些问题，并使其他人受益。\n我理解的是，gunicorn的worker进程实际上是Heroku web dyno的虚拟副本。换句话说，不应将Gunicorn的worker进程与Heroku的worker进程（例如Django Celery任务）混淆。\n这是因为Gunicorn的worker进程专注于处理Web请求（基本上是提高Heroku Web Dyno的性能），而Heroku Worker Dynos专门用于远程API调用等长时间运行的后台任务。\n我有一个简单的Django应用程序，对远程API有很好的利用，并且我想优化资源平衡。我还在大多数请求中查询PostgreSQL数据库。\n我知道这只是一个过于简化的表述，但我是否正确地思考了这些事情？\n一些相关信息:\n[https://devcenter.heroku.com/articles/process-model]\n[https://devcenter.heroku.com/articles/background-jobs-queueing]\n[https://devcenter.heroku.com/articles/django#running-a-worker]\n[http://gunicorn.org/configure.html#workers]\n[http://v3.mike.tig.as/blog/2012/02/13/deploying-django-on-heroku/]\n[https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/gunicorn/]\n其他与此主题相关的有用的SO问题:\n[Troubleshooting Site Slowness on a Nginx + Gunicorn + Django Stack]\n[Performance degradation for Django with Gunicorn deployed into Heroku]\n[Configuring gunicorn for Django on Heroku]\n[Troubleshooting Site Slowness on a Nginx + Gunicorn + Django Stack]
Heroku Worker Dynos是Heroku提供的一种服务，类似于一个完整的计算机。使用Procfile文件，可以为每个dyno指定一个命令，并在该命令上运行。这个命令会定期刷新并在崩溃时重新运行。然而，对于运行单线程web服务器来说，浪费整个计算机的资源是不划算的，因此需要使用Gunicorn来解决这个问题。
Gunicorn的主线程充当代理服务器，会生成多个应用程序的副本（workers），并将HTTP请求分发给它们。它利用了每个dyno实际上具有多个核心的事实。选择worker的数量取决于应用程序运行所需的内存量。
与Bob Spryn在上一个评论中所说的相反，还有其他的方法来利用此并行运行多个服务器的机会。最简单的方法是创建一个独立的子Procfile，并从主Procfile中运行全Python的Foreman等价物Honcho，按照指南中的说明进行操作。在这种情况下，单个dyno命令是一个管理多个单独命令的程序。这有点像从精灵那里得到一个愿望，并将这个愿望用于获得更多愿望。
这种方法的优点是可以充分利用dyno的容量。但缺点是，在共享dyno时，无法独立地扩展应用程序的各个部分。当扩展dyno时，会扩展所有复用的内容，这可能是不希望的。可能需要使用诊断工具来决定何时将服务放在自己的独立dyno上。
有没有办法知道Heroku Dyno有多少个核心？如果处理它们的worker多于核心数，那么这样做是没有意义的！
如果应用程序受到I/O限制（大多数情况下是这样），那么即使核心数不同，通过Gunicorn生成多个worker per dyno也能获得一些优势。这个文档提供了一些有关此问题的详细信息。
要获取各种等级的Dyno可以拥有的操作系统进程数量的更多信息，请参阅该文档的“Process”部分。
通过使用Gunicorn的worker进程和Heroku的worker dyno，可以在Heroku上有效利用资源，并提高应用程序的性能。