9

Azure Web ロールとSQL Azure 待機時間

こんにちは、 Web ワーカー ロールとSQL Azureの間にレイテンシとタイムアウトがあることを知っておくために、タイムアウトを発生させることがあります (これらはランダムではなく、頻繁に発生します)。

Web ワーカー ロールと SQL Azure が同じデータ センターにある場合 内部ネットワークを使用して通信しているときにタイムアウトが発生する理由

添付のスクリーンショットを参照してください。

ここに画像の説明を入力

この Web ワーカー ロールで実行されるアプリケーションには、謎のパフォーマンスの浮き沈みがあります..さまざまな理由が原因である可能性がありますが、知っておく必要があるのは、待ち時間とタイムアウトに関するこれらの統計が Web アプリケーションのパフォーマンスに影響を与えるかどうかです。.

ありがとう、

4

2 に答える 2

17

これを別のスレッドに投稿しましたが、古くて閉鎖されました。あなたの問題のいくつかを強調していると思います。

ビジネス アプリをクラウドに移行しようとしています。オンサイト サーバーが 8 年以上使用されていることを考えると、Azure サービスで顕著な改善が見られるはずです。しかし、アプリをテストし、クラウドとオンサイトのベンチマークを行ったところ、クラウドではオンサイト (8 年以上前のサーバー) よりも全体的に約 3 倍の遅延があり、最新の機器を使用してそれらを比較すると、20 倍の遅延があることがわかりました。私たちのアプリは asp.net アプリで、DB のサイズは約 11 GB です。

SQL Azure とパフォーマンス

  1. クラウドでプールされた接続を使用しないでください。そうすると、クエリが左右中央にドロップされます。代わりに、1 つの接続を開き、完了するまで開いたままにします。
  2. キャッシングを使用します。これを機能させる希望がある場合、選択の余地はありません。クラウド内に 1 つのサイトを正常に作成しましたが、適切なパフォーマンスを引き出すためにキャッシュを使用する必要がありました。
  3. それはあなたのせいではないことを認識してください！Azure チームは、あなたよりも自分たちの目的を解決する必要があります。私たちには無駄のないアプリがあり、10 年間アップグレード、微調整、最適化を行ってきました。

コンセプトとしては Azure が好きです。私はオプションが好きです。拡張性は好きですが、パフォーマンスは好きではありません。Microsoft がこれにもう少し注意を払い、いくつかの変更を加えてくれることを願っています。

テスト

テストは、まったく同じデータにアクセスする一連のクエリを実行することによって行われ、オブジェクトの作成から破棄されるまでの応答時間を測定するカスタム関数を介してコードで行われます (DB への書き込みが強制されます)。このオブジェクトは、テスト対象のコードをラップします。

テストではキャッシュは有効にされていませんでしたが、コードと DB が以前に一度実行されることを許可し、DB サーバーがクエリを最適化する機会を持ち、Web サーバーがアセンブリを適切にロードできるように、最良の結果を得ました。

テスト 1 - Web と DB を同じ適切なマシンで実行

  • クアッドコア 2.5GHz、8GB RAM @ 800Mhz、1300 FSB および SQL 2005
  • 応答時間は290 ミリ秒です。

テスト 2 - 同じマシン上の Web と DB

  • SQL および Web on 2 Proc (デュアル コア 3.0GHz)、16GB RAM @ 200Mhz、200 FSB および SQL 2005 非常に古い IBM サーバー。
  • Web と SQL はどちらも互いにローカルです
  • 応答時間は 656ミリ秒です。

テスト 3 - DB とは別の Web

  • SQL on 2 Proc (デュアル コア 3.0GHz)、16GB RAM @ 200Mhz、200 FSB および SQL 2005
  • Web on 1 Proc デュアル コア 3.0GHz、8GB RAM @ 200Mhz、200 FSB
  • 本当に古い IBM サーバーです。
  • 一方のマシンで Web を実行し、もう一方のマシンで SQL を実行します。
  • 応答時間は 796ミリ秒です。

テスト 4 - 紺碧

  • Azure 上の中規模 VM
  • SQL Azure DB
  • 応答時間は 3,174ミリ秒です。

結論

  • 1 台のサーバーのシナリオから 2 台のサーバーのシナリオに移行したときの遅延の差は140 ミリ秒でした。
  • そのシナリオから Azure への移行は2,518 ミリ秒でした。これは、私の 8 年前のマシンよりも17.98 倍悪いパフォーマンスです。

彼らがこれを修正し、それがあなたにとっても問題であることを彼らに知らせるまで、それをしないでください.

于 2012-10-27T12:42:29.233 に答える
8

まず、Windows Azure SQL Databaseは、サービスとして提供されるマルチテナントの高密度RDBMSであることを知っておく必要があります。つまり、1台のサーバーがおそらく数百人の顧客によって使用されているということです。

また、サービス、特にWindowsAzureSQLデータベースのSLAについて理解することをお勧めします。0msの遅延があるとは誰も主張していません。WIndows AzureSQLDatabaseには「一時的な条件」などもあります。

推奨される読み物は、WindowsAzureSQLデータベースのパフォーマンスとエラスティックガイドです。

Webアプリケーションのパフォーマンスについては、パフォーマンスと弾力性のガイドを読んだ後、たまに発生する200msが主要なボトルネックではないと思います。

最初のコメントの後の更新

共有環境では常に浮き沈みがあります。また、クエリの実行時間も上下に変化することを期待する必要があります。これは、そのような環境や、設計して一緒に暮らす必要のある環境では避けられません。ここには魔法の杖はありません。また、Windows Azure SQLデータベースの場合、（私たちにとって）専用サーバーもありません。アプリに信頼性の高いSQLServerサービスが必要だと思われる場合は、Windows Azure仮想マシンを試して、自分でSQLServerクラスターを起動することをお勧めします。すべてが同じ可用性セットに含まれている場合、クラウドサービスとVM間の通信はより予測可能になると思います（これは単なる推測です）。

2番目と3番目のコメントの後に更新します。

はい、ライセンスの問題があるかもしれません（私はライセンスの専門家です）。あなたが開いたチケットは浮き沈みのためですか？もしそうなら、あなたはそれをエスカレートしようとするかもしれません（方法はわかりませんが、あなたはあなたのチケットIDを持っています、あなたはまた割り当てられたエンジニアとチケットについての電子メールを持っている必要があります-その電子メールへの全員への返信） 。また、チケットを作成したとき、問題のビジネスへの影響を反映するための小さなアンケートがあったに違いありません。次に、通常の応答時間がチケットに割り当てられている必要があります。その時間内にサポートが返ってこない場合は、間違いなくエスカレーションできます。

アップデート

私が持っている興味深い観察は、すべてのスクリーンショットで最初のパケットのみが遅延し、その後、すべての連続した遅延が0になることです。あなたが提供しているすべてのサンプルで。これが10回のうち10回のケースである場合は、レイテンシーに問題はありません。通常のpingで「-t」オプションを使用して4つを超えるパケットを送信し、監視することをお勧めします。100パケット程度で壊して、結果を観察することをお勧めします。私は4つのパケットサンプルを考慮しません。最初の1つだけが、パフォーマンスレビューの遅延を持っています。

于 2012-07-20T07:46:29.973 に答える