Heroku：Webダイナモとワーカーダイナモ？いくつ/どのような比率が必要ですか？

HerokuでのWebダイノとワーカーダイノの違いについて知りたいと思いました。価格設定ページで一文説明をしているのですが、戸惑いました。それぞれをいくつ選ぶかをどうやって知ることができますか？目指すべき比率はありますか？私はこのようなものにかなり慣れていないので、誰かが詳細な説明をすることができますか、または私が必要とするダイノの数と種類を計算することができる何らかの方法がありますか？

また、各ダイノの時間数が何を意味するのか混乱しています。

http://www.heroku.com/pricing

私もこの記事に出くわしました。彼らの提案された解決策の1つとして、彼らはダイノの量を増やすと言いました。彼らはここでどのタイプのダイナモを参照していますか？

http://devcenter.heroku.com/articles/backlog-too-deep

より多くのdyno（Cedarのプロセス）が必要な場合の最良の指標は、herokuログです。ログを調整できるように、必ず拡張ログ（無料）にアップグレードしてください。

heroku.routerエントリを探していますが、最も関心のある値はキュー値です。これが常に0より大きい場合は、dynoを追加する必要があることを示しています。基本的に、これは、プロセスが処理できるよりも多くのリクエストが着信するため、キューに入れられることを意味します。データを返さずにキューに入れられる時間が長すぎると、タイムアウトになります。

私が恐れている理想的な比率はありません。アプリが1秒間に100のリクエストを実行し、多くのWebプロセスを必要とする可能性がありますが、ワーカーを利用していません。メールの送信などのバックグラウンドで処理を行う場合にのみ、ワーカープロセスが必要です。

psバックログが深すぎると、DynoWebプロセスが原因になります。

更新：2013年3月26日、Herokuはログアウトプットからキューフィールドと待機フィールドを削除しました。

キューフィールドと待機フィールドは、ルーターのログメッセージから削除されました。また、Herokuルーターは、着信リクエストに対してX-Heroku-Dynos-In-Use、X-Heroku-Queue-Depth、およびX-Heroku-Queue-Wait-TimeHTTPヘッダーを設定しなくなりました。

Dynosは基本的に、インスタンスで実行されるプロセスです。新しいCedarスタックを使用すると、任意のシェルコマンドを実行するように設定できます。Webアプリケーションの場合、通常、ユーザーからのHTTP要求への応答を担当する「web」と呼ばれる1つのプロセスがあります。他のすべてのプロセスは、以前は「ワーカー」と呼ばれていたものです。これらは、cron、処理キュー、およびWebプロセスを拘束したくない重い計算などのためにバックグラウンドで継続的に実行されます。各タイプのプロセスをスケーリングして、各タイプの複数のプロセスを起動して同時実行を追加することもできます。使用するそれぞれの量は、実際にはアプリケーションのニーズとアプリケーションが受ける負荷によって異なります。New Relicプラグインなどのツールを使用して、これらを監視できます。

多くの人が、既知の比率はなく、必要な「バックグラウンド」ワーカーに対するWebワーカーの比率は、アプリケーションの設計方法に依存していると述べています。これは正しいことです。ただし、一般的な経験則として、Webワーカー（つまり、Webワーカーが提供するコントローラーアクション）を非常に高速かつ非常に軽量にして、ブラウザーアクションからの応答時間の待ち時間を短縮することをお勧めします。たとえば、処理に約0.5秒以上のリアルタイムを必要とするブラウザアクションがある場合は、そのアクションの大部分をキューにプッシュするある種のシステムを設計することをお勧めします。

次に、このキューにサービスを提供するオフラインワーカーダイノを設計します。出力で保留中のHTTP応答がないため、はるかに長い時間がかかる可能性があります。おそらく、アクションをプッシュした最初のブラウザリクエストからレンダリングしたページは、リクエストが5秒ごとに終了したかどうか、またはそれらの行に沿った何かを確認するスレッドを開始するJavascriptを提供します。

他の人が与えたのと同じ理由で、私はまだあなたに協力する比率を与えることはできませんが、うまくいけば、これはあなたがあなたのアプリを設計する方法を決めるのに役立つでしょう。（これは、多くの有効なデザインのうちの1つのデザインにすぎないことにも言及する必要があります。）

https://stackoverflow.com/a/19965981/1233555-Herokuはランダムルーティングに移行したため、一部のdynoは、他のdynoが空いている間、キューをスタックすることができます（長いリクエストを処理します）。すべてのリクエストがWebdynoで非常に迅速に処理されるようにすることで、これを回避します。これにより、必要なWebダイノの数が減りますが、より多くのワーカーダイノが必要になります。

また、一部のRails構成でのみ実行される同時実行をサポートするWebアプリにも注意する必要があります。Unicorn、またはThinで慎重に記述されたコード（EventMachineをブロックしないI / O用）を試してください。

おそらく、計算するのではなく、必要な各種類のダイノの数を確認する必要があります。NewRelicがdynoキューを報告していることを確認してください-上記のリンクを参照してください。

簡単に言うと、キューを抑えるために必要な数だけ必要です。

Johnが説明しているように、ログにキューが表示され始めた場合は、さらに多くのdynoが必要です。バックグラウンドキューが長くなりすぎているのがわかり始めた場合（この情報を取得する方法は、実装した内容によって異なります）、より多くのワーカーが必要になります。

アプリケーションの設計と使用法に大きく依存するため、比率はありません。