.NET WebアプリケーションとSQL Serverデータベース(2008 Standard)を実行する単一のサーバーがあります。データベースを別のサーバーに移動する予定ですが、ネットワークハードウェアをプロビジョニングするために、Webアプリケーションとデータベースの間のデータスループットをベンチマークしたいと思います。ポート1433は内部で監視できますか?もしそうなら、これを実行できるWindows 2008 R2ネイティブのツールはありますか、それともWireSharkのようなサードパーティアプリケーションが必要ですか?私の接続文字列はserver=localhost
を使用してデータベースを参照していますが、このポートで使用されている帯域幅を確認するために1433を利用することはまだ可能ですか?
基本的に、Webサーバーとデータベースサーバーの間にGbit接続と100 Mbit接続のどちらが必要かを判断しようとしています。これについての考えは大歓迎です。
7月8日更新
上記は大部分は無関係であることがわかったので、私は上記をハッシュ化しました。なんらかの理由で、100 Mbitと1 Gbitのスイッチには大きなコストの違いがあると思いました。安価なホームユーザースイッチのみが100 Mbitです。他の人が指摘したように、WiresharkはIISと同じボックス上のSQLサーバーの間のアクティビティをピックアップしません。今のところ1Gbitマネージドスイッチを使用しているので、Wiresharkまたは後で何が起こっているかを確認するためにスイッチに組み込まれた監視ハードウェアによって課される物理的な転送制限に近いとは思いません。
私が理解しているように、IISでホストされているWebアプリケーションとSQL Serverの間のネットワークトラフィックを監視する必要があります。どちらも同じサーバー上で実行されています。これは、いくつかのこと:
ほとんどのパケットスニファーは、Webアプリがlocalhostまたは127.0.0.1上のSQL Serverに接続している場合に使用しているようなループバックインターフェイスを介したトラフィックの監視をサポートしていません。 Microsoftのメッセージアナライザーは例外ですが、ベータ版であり、視覚化ツールや分析ツールの多くを備えているようには見えません。また、適切なスループット分析ツールを備えたネットワークスニッファーが読み取れる形式にエクスポートできないようです。
SQL Serverへの接続にTCPの代わりに共有メモリまたはローカルの名前付きパイプを使用している場合、トラフィックは分析できません。
Wiresharkは、パケットが送信または受信されたプロセスIDも認識しません。これは、フィルタリング要件によっては問題になる可能性があります。
Wiresharkには、他のネットワークスニファと比較して、スループットグラフや会話の統計など、優れた視覚化および分析ツールがあります。プロセスIDでフィルター処理する必要があった過去に私が行ったことは、nmcapまたはネットワークモニターでキャプチャし、Wiresharkにインポートして分析を行うことでした。ただし、ループバックを介して接続している場合、またはローカルの名前付きパイプまたは共有メモリを介して接続している場合は、これらは機能しません。
今日は不要な場合でも、可能であれば1 Gbpsのスイッチを取得するというアドバイスに同意します。今は必要ない場合は後で必要になる可能性があり、ネットワークが飽和している緊急事態よりも、アプリのパフォーマンスが良好なときに計画的にアップグレードする方が簡単です。
年に数回、データベースサーバーへの100 mbpsリンクを飽和させることができるWebアプリに遭遇するので、これは風変わりなシナリオではないと思います。ただし、私がサポートするアプリケーションの多くは適切に設計されていないため、すべてのページビューで巨大な結果を取得しないなどの常識的な設計原則を使用している場合、これは問題にはなりません。
特定のポートを介してバイトを記録するための組み込みメソッドを認識していないため、本当にがその詳細レベルを必要とする場合、Wiresharkが適しています。
サーバーがSQL Server専用である場合、ネットワーク上のトラフィックの大部分が関連していると確信できるので、perfmonカウンターNetwork Interface\Bytes Total/Sec
は、幅広いガイドラインを提供します。
正直なところ、それは私の本のミュートポイントです。サーバーがホストされているギグポートに大きくて無意味な追加コストがない限り、それを採用してください。
DMV sys.dm_exec_connections
には、送信/読み取りバイト数を含む、トラフィックの接続ごとの統計があります。ただし、物理接続が閉じられるたびにリセットされ、スループット、特にスパイクの悪い指標でもあります。
そうは言っても、クライアントとサーバー間のトラフィックは問題になりません。特にWebアプリの場合、大きな戻り値セットはいずれにしても適切ではありません。スループットからではなく、ネットワークカードの割り込みレートから問題が発生するのははるかに早くなります。
ただし、スループットはデータベースの操作に関連する他の多くのアクティビティで主要な役割を果たします。