1

アプリ サーバーをスケールアップして、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 リクエストを停止し (外部サーバーで待機しているため)、待機中に別のリクエストを受け取る可能性が開けますか? もしそうなら、これはユニコーンやプーマと比較してパフォーマンスを追求する価値のある手段ですか? (アプリのランタイム アクティビティに強く依存しますか?)

4

1 に答える 1

2

Unicorn は、シングル スレッド、マルチプロセスの同期アプリ サーバーです。この種の処理には適していません。

アプリケーションが I/O バウンドのようです。これは、イベント指向のデーモンがリクエストを処理することを主張しています。

EventMachine と em-http-request およびem-http-serverを試すことをお勧めします。

これにより、http サーバーへの着信要求と発信 HTTP サービス呼び出しの両方を非同期で処理できます。

于 2014-02-26T18:51:22.303 に答える