問題タブ [puma]

一部のガイド (例) では、これを使用して Web サーバーを起動することを推奨しています。

しかし、私はいつもサーバーをpuma直接起動しました

経由で puma (または他のサーバー) を起動すると、何か特別なことが起こりますrails serverか?

前に質問しようとしましたが、何を調べようとしているのかよくわかりませんでした。

私はクライアント用のアプリを構築しています。彼は、ユーザーをページに移動させ、特定の時間にそれらすべてのユーザーに同時にデータをプッシュしたいと考えています。

たとえば、午後 4 時 15 分に全員に同じリンクを送信できるようにしたい場合があります。

とにかく、これはサーバー送信イベントの完璧な使用例のように思えました。私はsseにあまり詳しくありませんが、調べてみようと思いました。この Railscast から始めました: http://railscasts.com/episodes/401-actioncontroller-live

これは、ページの新しいユーザーごとに新しい同時接続が必要であることを示唆しているようです。この回答は、次のことを確認しているようです: Server Sent Events と Rails Streaming

ページの新しいユーザーごとに、新しいスレッドを実行する必要がありますか? 新しいスレッドは新しい同時接続と同じですか? 100,000 人のユーザーがいた場合、それは途方もない量のスレッドになります。

これを行うためのより良い方法について何か提案はありますか?

Rails 4 + Devise 3.2 アプリケーションの機能で、ユーザーが AJAX POST を介して次のアクションにパスワードを変更できるようにする機能で奇妙な問題が発生しています。ユーザーがパスワードを変更した後、後で 1 つ以上の要求を行った後、強制的にログアウトされ、再度サインインした後も強制的にログアウトされ続けるようです。

このアクションは実際には開発では問題なく機能しますが、マルチスレッド、マルチワーカーの Puma インスタンスを実行している場合、本番環境では失敗します。発生しているように見えるのは、リクエストの 1 つが別のスレッドに到達するまでユーザーがログインしたままになり、その後Unauthorized401 応答ステータスでログアウトされることです。単一のスレッドと単一のワーカーで Puma を実行すると、問題は発生しません。ユーザーが複数のスレッドで再度ログインしたままにできるようにする唯一の方法は、サーバーを再起動することです (これは解決策ではありません)。私が持っているセッションストレージ構成がそれを正しく処理すると思っていたので、これはかなり奇妙です。私のconfig/initializers/session_store.rbファイルには以下が含まれています：

MyApp::Application.config.session_store(ActionDispatch::Session::CacheStore, :expire_after => 3.days)

私のproduction.rb設定には以下が含まれます：

経由でプーマを起動していbundle exec puma -p $PORT -C ./config/puma.rbます。私のpuma.rb内容：

それで...ここで何がうまくいかないのでしょうか？パスワードが変更されたときに、サーバーを再起動せずにすべてのスレッド/ワーカーでセッションを更新するにはどうすればよいですか?

本番環境で Rubinius + Puma で padrino を実行している人はいますか? はいの場合、それはどのくらい安定していますか？MRI + Thinよりも優れていますか? 試してみようと思っていますが、安定性が少し心配です。

Rails 4 で複数のリクエストを同時に処理しようとしていますが、これは Rails 3 で非常に簡単に実行できましconfig.threadsafe!たPuma。

私がこのコントローラーを持っているとしましょう

puma -t 2:16 -p 3000以前は、 (最小 2 スレッドの場合) でpuma を開始し、ヒットindexしshowてからshow、適切にレンダリングすることができました。

Rails 4 で同じことをしようとすると、Puma はindexリクエストをロックし、showレンダリングされません。サーバーにアクセスすると、Puma から次のエラーがCtrl-C表示されます。

Rails 4 で並行処理を行うには何が足りないのでしょうか? config.threadsafe!必要ないはずです（試しても違いはありません）

ログに Rails 固有のエントリが表示されないのはなぜですか?

私はNginxプロキシでPuma 2.7.1を使用しています。通常のDebianボックスでは、何も派手ではなく、RVM経由でruby 1.9.3を使用しています。

私のプーマ設定：

次の方法で puma を起動します。

そうですか：

走る：

そうですか：

しかし、これ以上のログは表示されず、アプリケーションに関連するものは何もありません。

アプリケーションで例外が発生すると、ログに何も記録されません... "tabula rasa"

GIL/GVL で MRI を使用している場合でも、マルチスレッド環境での共有状態の基本的な問題を理解しています。しかし、MRI + Puma と jruby + Puma (両方のケースで Puma が複数のスレッドを使用するように構成されていると仮定) を検討する際に、異なる懸念があるかどうか興味があります。

また、前述のケースで共有状態を含む重要なセクションは何ですか?また、これは基本的に要求駆動型ではないプログラム (Puma のような Web サーバーを利用するものなど) ではどのように異なりますか?

お時間をいただき、ご検討いただきありがとうございます。これらのトピックに関する優れたリソースに関する推奨事項も大歓迎です。

アプリ サーバーをスケールアップして、1 分あたり 20,000 を超えるリクエストを処理しようとしています。

リクエストのストレス テストを行ったところ、ほとんどのリクエストは 20,000 RPM 以上を簡単に処理できました。

ただし、外部 HTTP 要求 (Facebook ログインなど) を行う必要がある要求は、サーバーをクロール (3,000 RPM) にします。

現在の環境の制限を概念的に理解しています。サーバーごとに 4 つのユニコーン ワーカーを持つ 3 つの負荷分散サーバーは、すべてのサーバーが HTTP 要求を待機している場合でも、一度に 12 の要求しか処理できません。

これをより適切にスケーリングするためのオプションは何ですか? 一度にもっと多くの接続を処理したい。

私が理解している可能な解決策：

1. 総当たり: より多くのユニコーン ワーカー (より多くの RAM) とより多くのサーバーを使用します。

2. すべてのブロッキング操作をバックグラウンド/ワーカー プロセスにプッシュして、Web プロセスを解放します。クライアントは、要求がいつ完了したかを確認するために、定期的にポーリングする必要があります。

3. プロセスの代わりにスレッドを使用できるように、Unicorn の代わりに Puma (およびおそらく MRI の Rubinius) に移行します。

基本的に、私が探しているのは、サーバーごとの接続数を増やすことができるように、単一のワーカーが処理できるブロック/キューに入れられたリクエストの数を増やすより良い方法はありますか?

たとえば、EventMachine で Thin を使用するという議論を聞いたことがあります。これにより、Rails ワーカーが現在作業中の Web リクエストを停止し (外部サーバーで待機しているため)、待機中に別のリクエストを受け取る可能性が開けますか? もしそうなら、これはユニコーンやプーマと比較してパフォーマンスを追求する価値のある手段ですか? (アプリのランタイム アクティビティに強く依存しますか?)