2009-03-03 16 views
2

私は現在、n層システムで作業していて、いくつかのデータベースパフォーマンスの問題にぶつかっています。 調査している領域の1つは、データベースサーバーとアプリケーションサーバーの間の待ち時間です。私たちのテスト環境では、 の2つのボックス間の平均ping時間は0.2msの領域にありますが、クライアントサイトでは8.2msの領域に多くなります。それは 私たちは心配する必要がありますか?データベースネットワークの待ち時間

あなたの平均的なシステムでは、共鳴するレイテンシをどのように考えますか、レイテンシをテスト/測定するにはどうしますか?

カール

答えて

4

要約:いいえ!あなたが監視する必要がある何

クエリのグローバルなパフォーマンスである(つまり、戻ってあなたのサーバにDB +実行+輸送への輸送)

何を行う可能性は時間をクエリ通常、監視するためのパフォーマンスカウンタを使用しています実行する。 結果がミリ秒の領域にあることがわかります。

"合理的な遅延"のようなものはありません。 「あなたのプロジェクトの合理的な待ち時間」を検討する必要があります。これは、あなたが取り組んでいるものによって大きく異なります。 リアルタイムの取引プラットフォームや読者限定のアマチュアWebサイトには、同じ期待はありません。

+0

SQLには組み込み機能もあります。 1msのフィルタを設定しないでください。そうしないと、より速く実行された操作が表示されません。 –

1

Linuxベースのサーバーでは、tcコマンドを使用して自分でレイテンシの影響をテストできます。 http://devresources.linux-foundation.org/shemminger/netem/example.html

:このコマンドは、すべてのパケットが、ここで利用可能遅延に

tc qdisc del dev eth0 root 

詳細を削除するにはeth0経由

tc qdisc add dev eth0 root netem delay 10ms 

使用このコマンドを行くに10msの遅延が追加されますたとえば

すべてのアプリケーションが異なりますが、10msのレイテンシがパフォーマンスに重大な影響を及ぼしている状況は間違いありませんシステムのnce。

1

answers.comのヘッドホンの1つは、調査によると、Webページの読み込みに400ミリ秒の待ち時間は、ページロードをキャンセルして他の場所に移動する人を初めて始めたときだと言いました。私のアドバイスは、オリジナルのクライアントリクエストからフルフィルメントまでのプロセス全体を見て、そこでうまくいけば、さらに最適化する必要はありません。 8.2msと0.2msは数学的に指数関数的に大きくなりますが、人間の感覚からは誰も実際に8.0msの違いを知ることはできません。なぜなら、彼らはレースで写真の仕上げをしているからです;)

2

申し訳ありませんが、私はこの質問に遭遇しましたが、他の人たちがアプリケーションサーバーとdbサーバーの間で達成したネットワークレイテンシのメトリックを探していました。とにかく、私は他の答えに気づいた

とにかく、要約:はい、ネットワーク遅延(pingによって測定)は大きな違いを生むことができます。

データベースレスポンスが.001msの場合、0.2msから8msへのpingからの大きな影響が見られます。私は、データベースプロトコルが混乱していると聞いたことがあります。これは、trueの場合、ネットワークの待ち時間がHTTPに比べて遅いということです。

1つのクエリを実行している場合は、8msを追加してデータベースからの応答を取得することは重要ではありません。しかし、一般的に悪いコードやORMの最適化されていない使い方で起こる10,000回のクエリを実行している場合、0.2msのpingに対しては4秒間しか待たないで、8msのpingを80秒間待つことになります。

私自身のポリシーの問題として、クライアントアプリケーションを直接データベースに直接接続させることはありません。クライアントアプリケーションは常にアプリケーションサーバー(REST Webサービスなど)を経由する必要があります。そうすれば、誤って「1 + N」のORM問題が発生しても、それほど影響はありません。私はまだ根本的な問題を解決しようとしています...

+0

もう一度古いスレッドを復活させましたが、私もこれを見つけました。私は、データベース活動の不安定さのために、データベースのRTT待ち時間を監視することが重要であることに同意します。私の会社が提供するツール(www.heimdalldata)には、他の多くの機能に加えて、アプリケーションへの影響を測定できるように、クエリに指定された量の遅延を追加する使いやすいメカニズムがあります。さらに、冗長クエリを特定するのに役立ち、ルールを使用してクエリまたはテーブルレベルでキャッシュを構成することもできます。高速クエリは、決してアプリケーションを離れることのないクエリです。 –

関連する問題