Pumaのワーカーとスレッドの違いは何ですか
Heroku dynoのコンテキストでのPumaワーカーとPumaスレッドの違いは何ですか？
私が知っていること（間違っている場合は修正してください）：
シンは同時ではないため、Webプロセスは一度に1つのリクエストしか実行できません
Unicornでは、1つのプロセスで複数のUnicornワーカーを使用して並行性を追加できることを知っています。
しかし、プーマにはスレッドとワーカーがあります。ワーカーはプーマプロセス内のスレッドではありませんか？
HerokuでWeb同時実行性を追加するために、より多くのワーカー/スレッドを使用できますか？
他の答えが述べているように、これは Herokuの記事 が特定の構成アイテムの説明にかなり適しています。
ただし、Herokuまたは任意の場所でアプリケーションを調整する必要がある場合は、物事がどのように機能するかを知ることは役に立ちます。
「ワーカーはpumaプロセス内のスレッド」と言うとき、あなたはほぼ正しいと思う。
私が理解している限りでは、pumaはオペレーティングシステムプロセスを分岐しますが、http要求に応答するためにworkers構成で何度も設定します。これにより、複数のリクエストを処理する点で並列性が得られますが、通常、各ワーカーのアプリケーションコードを「コピー」するため、より多くのメモリが必要になります。
各pumaワーカーは、threads構成に応じて、OSプロセス内で複数のスレッドを使用します。これらは、プーマプロセスが複数のリクエスト自体に応答できるようにすることで並行性を追加し、1つのスレッドがブロックされた場合、つまりリクエストを処理する場合、別のスレッドで新しいリクエストを処理できるようにします。前述のように、これにはアプリケーション全体がスレッドセーフであることが必要であるため、たとえば、あるリクエストからのグローバル設定が別のリクエストに「漏れ」ることはありません。
使用可能なCPUとメモリの数に対してワーカーの数が適切になるようにプーマを調整し、アプリケーションを実行しているホストをどれだけ飽和させたいかと、アプリケーションの動作に応じてスレッドを調整します-より多くは必ずしも同じではありませんより高速/より多くの要求スループット。
これは大きな領域であり、私は専門家ではありませんが...
Pumaは多くのワーカーを生成でき、各ワーカーは多くのスレッドを使用してリクエストを処理できます。
私が知る限り、Unicornにはスレッドはなく、ワーカーモデルのみがあります。
ただし、スレッドを使用する場合は、コードがスレッドセーフであることを確認する必要があります。これは、Rails、依存するすべてのgem、および独自のコードを意味します。
最大のパフォーマンスを得るために、適切なスレッドをサポートしている JRuby または Rubinius を調べることもできます。 MRIはGILによって制限されています。
Herokuの良い記事 があり、Pumaがワーカーとスレッドを使用する方法を説明しています。あなたはおそらくそれを読んで私を無視する必要があります:)
ここで参照されたHeroku/Pumaの記事の最も重要な行を強調したいだけです。
Railsは独自のデータベース接続プールを維持し、ワーカープロセスごとに新しいプールが作成されます。ワーカー内のスレッドは同じプールで動作します。
各ワーカーには独自のプールがあることを示しています。しかしながら：
ワーカー内のスレッドは同じプールで動作します。
これを理解することは非常に重要です。 Pumaワーカーがワーカーごとに5つのスレッドを使用する場合、各スレッドがデータベース接続を確立できるため、database.ymlを5の接続プールに設定する必要があります。
各ワーカーはシステムfork（）によって生成されるため、新しいワーカーには独自の5つのスレッドセットがあり、新しいRailsインスタンスが作成されると、database.ymlは5の接続プールに設定されたままです。
これで、database.yml接続プールと実際のデータベースプールは2つの異なるものになりました。データベースへのTOTAL接続では、Herokuのドキュメントで言及されている特定の式を使用する必要があります。
各アプリケーションが必要とする接続の数を決定するための適切な式は、Rails_MAX_THREADSにWEB_CONCURRENCYを掛けることです。
これは、それぞれが5つのスレッドを持つ2つのワーカーを使用している場合、2 * 5 = 10であるため、10の同時接続を受け入れるようにデータベースを構成する必要があります。