2

私は最近、SoundCloudチームによって作成された素晴らしいブログ投稿を読みました。この記事では、ソフトウェアアーキテクチャの進化について説明しています。

http://backstage.soundcloud.com/2012/08/evolution-of-soundclouds-architecture/

「負荷分散と小さな待ち行列理論」のセクションでは、Sean Treadwayが、待ち行列理論と、待ち行列をより適切に使用する方法について説明しています。

彼が書きました：

キューに入れられないシステムが必要でしたが、キューに入れられた場合、キューでの待機時間は最小限でした。M / M / cモデルを極限まで追求し、「cをできるだけ大きくするにはどうすればよいか」と自問しました。</ p>

これを行うには、単一のRailsアプリケーションサーバーが一度に複数のリクエストを受信しないようにする必要がありました。

インフラストラクチャにHAProxyを追加し、最大接続数が1を超えるように各バックエンドを構成し、すべてのホストにバックエンドプロセスを追加して、バックエンドまでHTTPリクエストをキューに入れることで、常駐待機時間を大幅に短縮しました。任意のホストのプロセスが利用可能になります

どうやら、彼らはHAProxy + Railsサーバー（多分Mongrel）を使用しています。OK、HAProxyは着信要求を照会し、利用可能な場合にのみMogrel/Thinにディスパッチします。

たぶん私は完全に間違っているかもしれません;）、しかしApache + Passengerは同じことをしますよね？1つのキュー（着信要求を処理するApache）とCワーカー（子プロセス）

4

1 に答える 1

0

Apache + Passengerは、実際に着信リクエストをラックバックエンドに配布します（リクエストが静的リソースを参照している場合を除き、apacheはそれ自体で処理します）。

このモデルは、1つのホストがすべて（！）のラックインスタンスを実行できる限り機能します。より多くのインスタンスが必要になると、apacheはそれを処理できなくなり、何かを上に置く必要があります（多くの場合HAProxy）。しかし、apacheの機能は、ラックベースのアプリを提供するよりもはるかに大きくなります。したがって、特に、ホストごとに1回デプロイするため、より軽量なもの（nginxなど）に置き換えるのが理にかなっています。

それが少しお役に立てば幸いです。

于 2012-09-02T16:34:54.413 に答える