データベースネットワークの遅延

Question

現在、n層システムで作業しており、データベースのパフォーマンスの問題と戦っています。 私たちが調査してきた1つの領域は、データベースサーバーとアプリケーションサーバー間の遅延です。テスト環境では 2つのボックス間の平均ping時間は0.2ミリ秒程度ですが、クライアントサイトでは8.2ミリ秒程度です。あれですか 心配するべきことは何ですか？

平均的なシステムでは、妥当なレイテンシーをどのように考えていますか？レイテンシーをどのようにテスト/測定しますか？

カール

Answer 1

要するに：いいえ！

監視する必要があるのは、クエリのグローバルパフォーマンスです（つまり、DBへの転送+実行+サーバーへの転送）

できることは、パフォーマンスカウンターを使用して、クエリの実行に通常かかる時間を監視することです。 おそらくミリ秒単位の結果が表示されます。

「合理的な待ち時間」などはありません。むしろ、「プロジェクトの合理的な待ち時間」を考慮する必要があります。これは、作業内容によって大きく異なります。 リアルタイム取引プラットフォームと読み取り専用のアマチュアWebサイトに対して、人々は同じ期待を抱いていません。

Answer 2

非常にタイミングの悪い応答は申し訳ありませんが、他のユーザーがアプリサーバーとデータベースサーバーの間で達成しているネットワーク遅延のメトリックを探していたときに、この質問につまずきました。とにかく、私は他の答えに気づいた

とにかく、要するに：はい、ネットワーク遅延（pingで測定）は大きな違いを生む可能性があります。

データベースの応答が.001ミリ秒の場合、0.2ミリ秒から8ミリ秒のpingに移行すると大きな影響があります。データベースプロトコルはおしゃべりだと聞いたことがあります。これは、trueの場合、httpに対してネットワーク遅延が遅いことにより影響を受けることを意味します。

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

私自身のポリシーの問題として、クライアントアプリケーションがデータベースに直接連絡することは決してありません。クライアントアプリケーションは常にアプリケーションサーバー（REST Webサービスなど）を通過する必要があります。そのようにして、誤って「1 + N」 ORMの問題であれば、それほど影響はありません。私はまだ根本的な問題を修正しようとします...

Answer 3

Linuxベースのサーバーでは、tcコマンドを使用して、遅延の影響を自分でテストできます。

たとえば、このコマンドは、eth0を経由するすべてのパケットに10ミリ秒の遅延を追加します

tc qdisc add dev eth0 root netem delay 10ms

このコマンドを使用して遅延を削除します

tc qdisc del dev eth0 root

詳細はこちらから入手できます。 http://devresources.linux-foundation.org/shemminger/netem/example。 html

すべてのアプリケーションは異なりますが、10ミリ秒の遅延がシステムのパフォーマンスに大きな影響を与える状況は間違いなく見ました。

Answer 4

answers.comの本部長の1人は、調査によると、Webページの読み込みの400ミリ秒は、ユーザーがページの読み込みをキャンセルして他の場所に移動するのを最初に開始したときだと言いました。私のアドバイスは、最初のクライアントのリクエストからフルフィルメントまでのプロセス全体を見ることであり、もしあなたがそこでうまくいっていれば、さらに最適化する必要はありません。 8.2ミリ秒と0.2ミリ秒は、数学的な意味で指数関数的に大きくなりますが、人間の感覚からは、8.0ミリ秒の差を実際に認識することはできません。彼らがレースで写真仕上げをする理由です;）