4

セットアップ：EC2サーバーはELBの背後で自動スケーリングし、RDS mysqlデータベースに接続し、すべての静的ファイルはクラウドフロントから提供されます。

EC2サーバーでnginxをWebサーバーとして実行しており、キープアライブを20に設定し、ワーカープロセス4 、。Codeigniterはバックエンドであり、codeigniterセッションを使用しています。

私は、パフォーマンス、包囲、apacheベンチマーク、blitz.ioをテストするために、多くのベンチマークを実行してきました。

私は2つの特定のページをテストしています。最初のパフォーマンスは非常に優れており、codeigniterセッションを使用しているため、データベースにアクセスしてci_sessionsデータベースを読み取って更新します。2番目のページは私が問題を抱えているページです。1人のユーザーで約0.4秒で完了する複数の結合でクエリを実行します。このクエリは最適化されており、私はInnoDBテーブルを使用しています。c10とn1000を使用したapacheベンチマークでは、リクエストの100％が634ミリ秒以内に返されます。

200を超える同時ユーザーを実行すると、問題が発生し始めます。EC2サーバーを追加しても効果はなく、CPUは約50％使用されています。RDSデータベースのモニタリングでは、CPUとメモリの使用量が70％未満であり、平均DB接続が35未満であることも示されています。

大規模なRDSインスタンスと大規模なEC2インスタンスに移行することでパフォーマンスが向上しました。これにより、ここでI/Oが機能するかどうか疑問に思います。

負荷テスト中にELBの外部でサーバーを起動し、このページにアクセスすると、1秒以内に戻ってきますが、ELB内で別のサーバーを起動すると、最大4〜5秒かかります。これは、私がRDSに過負荷をかけていないことを示しています。

ELBを5分間のバーストでゆっくりと立ち上げてみましたが、これは役に立たなかったようです。

RDSとEC2サーバーが機能にプッシュされていないように見えるため、I / Oの問題なのか、それとも他の問題なのか、この問題を次にどこで探すべきか疑問に思っています。次に見るべき提案やアイデアは大歓迎です

4

1 に答える 1

2

わかった。ご存じのとおり、これは非常に幅広いテーマです。しかし、私は努力して助けます。

  1. ELB は通常、バースト スケーリングがあまり得意ではありません。これについて Amazon のエンジニアと話し合ったところ、バーストで ELB をスケーリングすることは不可能であるため、彼らは実際には ELB をスケーリングしないことがわかりました。ELB をスケールアップするには、時間の経過とともに一貫した負荷が必要です。このため、haproxy に切り替えました。ELB はバースト負荷でスケーリングしないことに加えて、DNS ルックアップに CNAME を使用し、パフォーマンスにも影響します。そのため、バースト ロードを頻繁に行うことを計画している場合や、DNS ルックアップを要求する場合は、おそらく ELB を使用しないことをお勧めします。

  2. RDS はブラック ボックスです。それは完全に真実ではありませんが、バックエンドが簡単にスケーリングできる単純なセットアップであることがわかっていない限り、一般的には RDS を避けます。そうは言っても、RDS はスケーリングに役立ちますが、バックエンドを弱体化させて、クエリが迅速に実行されるようにします。通常の MySQL インスタンスで実行し、1 秒未満かどうかを確認します。私の経験では、クエリが「最適化されている」と言うとき、それは、私のドリフトをキャッチした場合に、クエリをさらに「最適化」する別の方法がないという意味ではありません。

于 2012-07-02T15:25:14.103 に答える