6

私は非同期 RESTful Web サービスを構築しており、最もスケーラブルで高性能なソリューションは何かを理解しようとしています。当初、私は FriendFeed 構成を使用する予定でした。nginx を実行する 1 台のマシンを使用して静的コンテンツをホストし、ロード バランサーとして機能し、動的コンテンツ用の Tornado Web サーバーを実行する 4 台のマシンへのリバース プロキシとして機能します。クアッドコア マシンで nginx を実行し、シングル コア マシンで各 Tornado サーバーを実行することをお勧めします。アマゾン ウェブ サービス (AWS) は、最も経済的で柔軟なホスティング プロバイダーと思われるので、ここに私の質問があります。

1a.) AWS では、c1.medium (デュアル コア CPU と 1.7 GB メモリ) インスタンス タイプしか見つかりません。これは、c1.medium で 1 つの nginx インスタンスを実行し、m1.small (シングルコア CPU と 1.7 GB メモリ) インスタンスで 2 つの Tornado サーバーを実行する必要があるということですか?

1b.) スケールアップする必要がある場合、これら 3 つのインスタンスを同じ構成内の別の 3 つのインスタンスにチェーンするにはどうすればよいですか?

2a.) S3 バケットで静的コンテンツをホストする方が合理的です。nginx はまだこれらのファイルをホストしていますか?

2b.) そうでない場合、nginx でホストしないとパフォーマンスが低下しますか?

2c.) nginx が静的コンテンツをホストしない場合、実際にはロード バランサーとしてのみ機能します。さまざまなクラウド構成のパフォーマンスを比較した優れた論文がここにあり、ロード バランサーについて次のように述べています。 SSL 処理のオーバーヘッドなしでレイヤー 4 のトラフィックを処理します。」ロードバランサーとして nginx をレイヤー 4 で動作するものに置き換えることをお勧めしますか、それとも Amazon の Elastic Load Balancer は十分に高性能ですか?

4

1 に答える 1

2

1a）Nginxは非同期サーバー（イベントベース）であり、単一のワーカー自体で多くの同時接続（max_clients = worker_processes * worker_connections/4 ref）を処理でき、それでも良好に機能します。私自身、c1.mediumの種類のボックス（awsではない）で約20Kの同時接続をテストしました。ここでは、ワーカーを2つ（CPUごとに1つ）に設定し、4つのバックエンドを実行します（さらにテストして、どこで壊れているかを確認することもできます）。これにより問題がさらに発生する場合にのみ、同様のセットアップをもう1つ実行し、弾性ロードバランサーを介してそれらをチェーンします

1b）（1a）で述べたように、弾性ロードバランサーを使用します。誰かがELBを20Kreqs/ secでテストしたのを見てください。彼らが興味を失ったので、彼はあきらめたので、これは制限ではありません。

2a）クラウドフロントとそのCDNで静的コンテンツをホストし、まさにこれを目的としています（S3よりも安価で高速であり、s3バケットまたは独自のサーバーからコンテンツをプルできます）。その非常にスケーラブル。

2b）明らかに、静的ファイルを提供するnginxでは、同じ数のユーザーに対してより多くのリクエストを提供する必要があります。その負荷を取り除くと、接続を受け入れてファイルを送信する作業が減ります（帯域幅の使用量が減ります）。

2c）。nginxを完全に回避することは良い解決策に見えます（仲介者が1人少なくなります）。Elastic Load BalancerはSSLターミネーションを処理し、バックエンドサーバーのSSL負荷を軽減します（これにより、バックエンドのパフォーマンスが向上します）。上記の実験から、それは約20Kを示し、その弾力性があるので、ソフトウェアLBよりも伸びるはずです（その動作についてはこの素晴らしいドキュメントを参照してください）

于 2011-03-06T09:52:32.213 に答える