Note
この記事は、3 部構成のシリーズに含まれています。 ネットワークの問題 基になる TCP/IP パフォーマンス および パート 3: TCP/IP パフォーマンスの既知の問題を確認できます。
TCP/IP (伝送制御プロトコル/インターネット プロトコル) のパフォーマンスは比較です。 比較は、ハードウェア、ネットワーク パス、オペレーティング システム (OS) の同一のエンドポイントで実行される必要があります。 実際のパフォーマンスは、複数の要因が関係してボトルネックを引き起こしている可能性があるため、異なります。 これらの要因は、多くの場合、基になるネットワーク、TCP の設計、およびストレージ IO の実際の送信速度です。
パフォーマンスチューニングの詳細についてはエンドポイントに最適な構成を設定します。
TCP 受信ウィンドウの自動チューニング は、待機時間の長いネットワークで帯域幅を利用するために接続をスケールアップするために使用されるアプリケーション定義の機能です。 たとえば、TCP が標準に自動チューニング レベルを使用するように構成されていて、アプリケーションに TCP ウィンドウ用に十分なバッファーが定義されている場合、OS は TCP を最大にすばやくスケーリングします。 ただし、この機能は、待ち時間の長いネットワーク用に設計されています。 待ち時間の短いネットワークの場合、その場で (ネットワーク インフラストラクチャなど) 多数のセグメントが存在しないため、このような要件はありません。
TCP ウィンドウが一度に最大にスケーリングされない待機時間の長いネットワークの場合は、帯域幅遅延積 (BDP) を決定し、それに応じてウィンドウをスケーリングするために、 CUBIC、 NewReno、 Tcp などのアルゴリズムがあります。 Windows OS では、作成された各ソケットに輻輳アルゴリズムが割り当てられます。
TCP 設定は Windows 10 で事前に定義されています。 Get-NetTCPSettings コマンドレットを使用して TCP 設定を取得し、Get-NetTCPConnection コマンドレットを使用して、ローカルまたはリモートの IP アドレス、ローカルまたはリモート ポート、接続状態などの TCP 接続プロパティを表示します。
スループットを向上させるヒントを次に示します。
- 基にネットワークの問題 (パケット損失) がないことを確認します。
- ネットワークの互換性に関する問題がある場合やトラブルシューティング目的は除き、NIC の高度なパフォーマンス機能 (Jumbo フレーム、RSS/VMQ、オフロード機能、RSC など) のプロパティを有効にします。
- TCP の自動設定レベルで通常が使用されるように構成されていることを確認します。
- CPU またはストレージのボトルネックが発生しないよう、パフォーマンス モニター分析を使用します。
- 組織の実際の要件に基づいてセキュリティ機能を選択します。
- ベースラインを作成します。
TCP スループットのテスト ツール
特定のハードウェアで可能な限り高いスループットを達成するには、パフォーマンス要因を調整する必要があります。 基になるネットワークの問題 (パケット損失) がないことを確認します。 NTttcp.exeまたはctsTraffic.exe ツールを使用してスループットをテストします。 ネットワーク ワークロードの パフォーマンス ツールを参照してください。
TCP スループットのボトルネック
TCP スループット テスト中は、ネットワーク モニターを使用したり、ネットワーク パケット レベルのログを取得したりしないでください。 ネットワーク ドライバー インターフェイス仕様 (NDIS) 監視フィルターは、パケットが記録されるたびに送信者と受信者の遅延を追加します。 この操作では、CPU リソースが必要になり、多くのストレージ IO が生成されます。 TCP がパケット損失から 回復しようとしているため、パケット レベルのログを取得すると、パフォーマンスが低下。
セキュリティの追加には、独自のコストとパフォーマンスの問題があります。 インターネット プロトコル セキュリティ (IPsec) などのセキュリティ プロトコルには、オーバーヘッドと追加の処理要件があります。 データ保護とデータ整合性を比較すると、処理コストを削減するために IPsec の整合性モードを優先する必要があります。 セキュリティ ソフトウェアはパケット処理にも大きなコストがかかるため、出力が遅くなります。
テストされたパフォーマンスが期待どおりにならない場合は、 Network 関連のパフォーマンス カウンターで定義されているログを取得します。
TCP パフォーマンスの問題を確認したら、ファイル システム プロトコル (サーバー メッセージ ブロック (SMB) やネットワーク ファイル システム (NFS) など)、上位レイヤーに関連付けられているプロトコルを確認します。 これらのプロトコルには、プロセッサ リソースとディスク IO が必要です。 低速は、ドライバーまたはハードウェアの障害、高遅延プロシージャ コール (DPC) キューまたは低速ディスク IO によって発生します。 Xperf/Windows Performance Recorder (WPR) (CPU) ログを使用した分析を必要とするため、OS のどのコンポーネントが高い DPC を引き起こしているかを見つけることは困難です。 ディスク関連の低速の問題を見つける方が比較的簡単です。 詳細については、「 ディスクパフォーマンスの最適化とチューニングを参照してください。
テスト中、テスト アプリケーション (クライアント アプリケーションとサーバー アプリケーション) を調整して、バッファー値が最大スループットに達するのに十分な高い複数のスレッドを使用できます。 ただし、各 API 呼び出しで使用できるスレッドとバッファーの数はプログラミングに基づいて制限されるため、実際の条件が反映されない場合があります。 さらに、アプリケーション層プロトコル (SMB または Common Internet File System (CIFS) には、独自のバッファーと最適化 (ファイル サーバーのパフォーマンス チューニング または SMB: トラブルシューティング ガイド) があります。 アプリケーションがベースラインで想定どおりに動作しない場合は、アプリケーションスペシャリストと協力してボトルネックを見つけてください。
ベースラインを作成する方法
現在のスループットを比較するには、パフォーマンスのベースラインを作成する必要があります。 ネットワークの理解を深めるために、デプロイの開始時にベースラインを作成します。
ベースラインは、次の主要なポイントによって形成されます。
- 送信元ネットワークと移行先ネットワーク
- これらのネットワーク間の待機時間とホップ数
- プロセッサ/インターフェイスの機能と構成
- テストの期間 (稼働時間/非稼働時間/ピーク時)
- OS のバージョン
- スループット プルとスループット プッシュ
Note
処理能力をほぼ等しく保つために、同じサーバー モデル (NIC カードとプロセッサ容量の同じ数) を使用してベースラインを作成します。
バッファーを監視し、テスト ツールによって作成されたトランスポート セッションの数を追跡します。 4 つの同時 TCP トランスポート セッションで、RSS が有効になっている状態で CPU を均等に利用して評価できます。
スループットを測定し、ベースラインを作成する手順を次に示します。
ctsTraffic ツールをダウンロードします。 ctsTraffic ツールのいくつかのパラメーターの説明を次に示します。
パラメーター 説明 -listen:<IP/*>このオプションは、サーバーでのポート リッスンに使用されます。 *が指定されている場合、ctsTraffic ツールは、そのマシンで使用可能なすべての IP アドレスをリッスンします。 たとえば、-listen:*のようにします。-target:<IP>このオプションはクライアントで使用され、ctsTraffic.exeが実行され、リッスン状態にあるサーバーの IP アドレスを指定します。 たとえば、 -target:192.168.1.10のようにします。-pattern:pullCtsTraffic ツールでは、既定でプッシュ パターンが使用されます。 つまり、データはクライアントからサーバーに送信されます。 このスイッチをクライアントとサーバーの両方で使用すると、データはクライアントで受信されます。 プッシュ テストを実行するときは、このオプションを使用しないでください。 -connections:<num>このオプションは、TCP 接続の数を指定します。 TCP ソケットは、クライアントから同時に作成されます。 ミッドレベル ネットワーク カードの RSS キューは 8 であるため、8 個が一般的に使用されます。 たとえば、 -connections:8のようにします。-iterations:<num>このオプションは、 -connections:内の接続の乗算数を指定します。 たとえば、-iterations:10のようにします。 10 回の反復で、クライアントは合計で 80 個の接続を試行します。 このオプションを指定しない場合、クライアントは 1000 接続まで 8 つの接続を試行し続けます。-statusfilename:<filename.csc>このオプションを使用して、コンソール レベル 1 オプションを Microsoft Excel と互換性のある .txtファイルにフラッシュします。-connectionfilename:<filename.csv>詳細な詳細をフラッシュするには、このオプションを使用します。 たとえば、各ソケットがデータを転送するのにかかった時間などのソケット レベル情報です。 このオプションを使用して、エラーや高度なトラブルシューティングがあるかどうかを確認できます。 -consoleverbosity:<0|1|2|3>このオプションは、テストの実行中にモニター上のビューまたは出力を指定します。 たとえば、 -consoleverbosity:1のようにします。受信側でリソース モニターを開きます。 たとえば、
-pattern:pullを使用する場合は、クライアントで開き、それ以外の場合はサーバーで開きます。サーバーで ctsTraffic ツールを起動し、次のコマンドを実行します。
Ctstraffic.exe -listen:* -consoleverbosity:1 <-pattern:pull>
クライアントで ctsTraffic ツールを起動し、次のコマンドを実行します。
Ctstraffic.exe -target:<serverip> -consoleverbosity:1 <-pattern:pull> -connections:8 -iterations:10
受信側のプロセッサが均等に使用されていることを確認します。 そうでない場合は、RSS に関する問題を確認して、期待どおりに動作しない問題を確認してください。
クライアントの結果に従って、ビット/秒でスループットを計算します。 次のスクリーンショットの例を参照してください。
この例では、スループットはほぼ 19 Gb/秒であり、次のように計算されます。
(85,899,349,200 バイト/36.678 秒) * 8 = 18,735,885,097.33355 (ビット/秒)