7

コミュニティが私のために何かを明確にし、他の人が利益を得ることができることを願っています.

私の理解では、gunicorn ワーカー プロセスは本質的に Heroku Web dyno の仮想レプリカです。つまり、 Gunicorn のワーカー プロセスを Heroku のワーカー プロセス(Django Celery Tasks など)と混同しないでください。

これは、Gunicorn ワーカー プロセスが Web リクエストの処理 (基本的には Heroku Web Dyno のパフォーマンスの調整) に重点を置いているのに対し、Heroku ワーカー Dyno は長時間実行されるバックグラウンド タスクであるリモート API 呼び出しなどに特化しているためです。

リモート API を適切に利用する単純な Django アプリがあり、リソース バランスを最適化したいと考えています。また、ほとんどのリクエストで 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 スタックでのサイトの遅さのトラブルシューティング

4

1 に答える 1

16

回答を提供し、人々がコメントを検索する必要がないようにするために、dynoはコンピューター全体のようなものです。Procfileを使用して、各dynoに実行するコマンドを 1 つ与えると、そのコマンドが起動し、定期的に再実行してリフレッシュし、クラッシュしたときに再実行します。ご想像のとおり、シングル スレッドの Web サーバーを実行しているコンピューター全体を無駄にするのはかなり無駄です。そこでGunicornの出番です。

Gunicorn マスター スレッドは、プロキシ サーバーとして機能するだけで、指定された数のアプリケーション (ワーカー) のコピーを生成し、それらの間で HTTP 要求を分散します。各ダイノが実際に複数のコアを持っているという事実を利用しています。誰かが言ったように、選択する必要があるワーカーの数は、アプリの実行に必要なメモリの量によって異なります。

前回のコメントで Bob Spryn が言ったこととは反対に、この並列処理の機会を利用して、同じ dyno で別々のサーバーを実行する方法は他にもあります。最も簡単な方法は、別のサブ procfile を作成し、これらの指示に従って、メインの Procfile からすべてPython のForemanに相当するHoncho を実行することです。基本的に、この場合、単一の dyno コマンドは、複数の単一コマンドを管理するプログラムです。ジーニーの願いをひとつ叶えて、その願いをさらに4つ叶えるようなもの。

これの利点は、dyno の容量を最大限に活用できることです。このアプローチの欠点は、dyno を共有している場合、アプリの個々の部分を個別にスケーリングできなくなることです。dyno をスケーリングすると、多重化したすべてがスケーリングされますが、これは望ましくない場合があります。サービスを独自の専用 dyno にいつ配置する必要があるかを判断するには、おそらく診断を使用する必要があります。

于 2013-04-11T17:00:20.117 に答える