配信ウィンドウに必要な実効転送レートを計算し、完全な経路を測定してください。ポート容量、ラウンドトリップ時間、TCP動作、ストレージ、アプリケーション処理がすべて結果に影響します。現実的な同時実行で制御されたテストを使用し、ネットワーク層を選択する前に実際のアプリケーションを通じて繰り返してください。
配信ウィンドウをレートに変換する
有用なアプリケーションデータの量と、それを配信するために利用可能な時間から始めます。10進単位を使用すると、2 TBを2時間で転送するには、プロトコルオーバーヘッドと中断を考慮する前に、約278 MB/秒のペイロード、つまり2.22 Gbpsが必要です。この計算は計画の例であり、測定されたサービス結果ではありません。
重複する転送を含めてください。スケジュールされたエクスポート、顧客のダウンロード、バックアップのアップロードは、月間合計が控えめに見えてもリソースを共有する可能性があります。月間平均だけでなく、ビジーピリオドのモデルを作成してください。どの方向が重要か、失敗した転送が再起動する必要があるか再開できるかを指定します。その動作はシステムが実行する作業量に影響します。
ポート容量と実効スループットを分けて考える
サーバーポートはリンク容量を表します。実効スループットは、観測された間隔中にアプリケーションが配信したデータを表します。暗号化、プロトコルフレーミング、再送信、ストレージアクティビティ、受信側での作業がその経路の一部を占めます。したがって、記載された10 Gbpsポートは、アプリケーションが10 Gbpsのペイロードを継続的に配信することを確立しません。
IETF RFC 6349は、ネットワーク経路のテストとTCPパフォーマンスの検査を明確に区別しています。この分離を自身の診断で使用してください。まず、エンドポイントとルートが適切であることを確認し、次にトランスポートとアプリケーションを調査します。購入したポートを増やしても、データを遅く書き込む受信側や、一度に1つのリクエストを処理するアプリケーションは修正されません。
ラウンドトリップ時間が重要である理由を理解する
TCPは、確認応答が返る前にどれだけのデータが飛行状態に留まれるかを制御します。帯域幅遅延積はこれに有用な尺度を与えます。レートにラウンドトリップ時間を掛けたものです。40ミリ秒のラウンドトリップ遅延がある仮想的な10 Gbps経路は、約50 MBが飛行状態にあることを表します。この計算は、レイテンシとトランスポート動作が高速計画に属する理由を説明します。
結果は、任意のソケット設定を適用する指示ではありません。オペレーティングシステム、輻輳制御、ネゴシエートされたウィンドウ、実際の経路が動作に影響します。チューニングの前に、現在のソフトウェアドキュメントを確認し、測定値を検査してください。より多くの並列接続は、状況によっては集約スループットを改善する可能性がありますが、アプリケーションが依存する個々の転送の動作を隠すこともあります。
制御されたテストマトリックスを構築する
所有しているか、テストを許可されているエンドポイントのみを使用してください。演習が通常のサービスを妨害しないよう、テストウィンドウとレートに合意してください。iperf3などのツールは、構成可能な方向、期間、並列ストリームを提供します。公式ドキュメントがそれらの制御を定義しています。別のオペレーターが再現できるよう、バージョン、エンドポイント、ルートコンテキスト、設定を結果とともに記録してください。
単一フローから始め、次に代表的な同時実行を追加します。アプリケーションが両方向に依存する場合は、両方向を実行してください。この例示的なマトリックスは、単一のヘッドライン結果では混ざってしまう質問を分離します。内部アドレスや運用詳細を明らかにする場合は、生の結果を非公開に保ち、決定に必要な測定値のみを公開してください。
| テスト | 調査内容 | 何を証明しないか |
|---|---|---|
| 1つのトランスポートフロー | 単一フローの経路動作 | 集約アプリケーション配信 |
| 複数の並列フロー | 同時実行と集約の制限 | 1人の顧客の転送レート |
| アプリケーション転送 | ストレージ、プロトコル、ソフトウェアの組み合わせ | すべてのデータセットのパフォーマンス |
| ビジーピリオドの繰り返し | 現実的なアクティビティ下での変動 | 永続的なスループット保証 |
テスト中にエンドポイントを確認する
両端でCPU使用率、メモリプレッシャー、ストレージアクティビティ、エラーカウンターを記録してください。エンドポイントの観測がない転送結果は、実際の制約を不可視にする可能性があります。1つのプロセスまたはCPUが飽和している間に他がアイドルであるかどうかを確認してください。複数の設定を一度に変更することは避けてください。どの調整が役立ったかを特定するのが難しくなります。
メモリバックのテストと、実際のデータを読み書きするテストを分離してください。前者はトランスポート経路の調査に役立ちます。後者はアプリケーションの作業のより多くを反映します。結果が大きく異なる場合は、メモリバックの数値を配信の約束として扱うのではなく、ストレージと処理を検査してください。スコープが明確であれば、両方の測定が有用です。
現実的なペイロードでアプリケーションをテストする
HTTPエクスポート、暗号化レプリケーションストリーム、ファイル転送セッションは、異なる処理パターンを持っています。代表的なファイルサイズ、リクエストレート、暗号化設定を使用してください。ユーザーがそのステップを待つ場合、最初のバイトが送信される前にデータを準備する時間を含めてください。最初の応答レイテンシと完了時間を区別し、一方を他方として報告しないでください。
変動を確認するのに十分な間隔でテストを繰り返し、構成を変更する前にベースラインを保持してください。仮想的な2 TBエクスポートの場合、実際の完了時間を2時間のウィンドウと比較し、中断のための余裕を残してください。理由なくポート容量を増やすのではなく、観測されたボトルネックに対して改善を選択してください。
結果を使用して構成を選択する
有用な出力は、証拠を伴うリソース要件です。測定されたペイロードレート、許容可能な完了時間、予想される同時実行、既知の制限段階です。SwissOctetネットワークバリアントをその要件と比較し、トラフィック許容量、CPU、ストレージ仕様を含めます。場所だけでは、すべての受信者へのルートやエンドツーエンドのレイテンシは決まりません。
展開後もテスト手順を保持してください。データセットが増加したり、ソフトウェアが変更されたり、ユーザーが別のネットワークに移動したときに再利用します。再現可能なベースラインは、パフォーマンスインシデントの診断を容易にし、孤立した速度テストや宣伝された最大値よりも、構成を変更するためのより確かな理由を提供します。
実践チェックリスト。
- ボリュームと期限からペイロードレートを計算する。
- 重複する転送と方向をモデル化する。
- 許可されたテストエンドポイントと制限に合意する。
- 単一フロー、同時実行、アプリケーションテストを比較する。
- テスト中に両方のエンドポイントを観察する。
- 再現可能なベースラインと有用な余裕を保持する。
重要な詳細。
より大きなTCPウィンドウは常に遅い転送を修正しますか？+
いいえ。まず経路とエンドポイントを診断してください。ストレージ、CPU、損失、アプリケーション動作が支配的になる可能性があり、トランスポートチューニングは実際のシステムに適合する必要があります。
なぜ単一フローと複数フローをテストするのですか？+
それらは異なる質問に答えます。集約容量は1つの転送のレートより高くなる可能性があります。アプリケーションの同時実行が、どの結果が重要かを決定します。
任意のパブリックサーバーに対して容量テストを実行できますか？+
制御しているか、テストの許可を得ているエンドポイントを使用してください。測定が無関係なサービスを妨害しないよう、期間、レート、タイミングに合意してください。
出典へ。
これらの参考文献は、このガイドの技術的概念をサポートしています。本番システムを変更する前に最新のドキュメントを確認してください。
- IETF RFC 6349：TCPスループットテストのフレームワーク datatracker.ietf.org
- ESnet: iperf3の呼び出し software.es.net
SwissOctetによる編集ガイダンス。例は例示目的です。サービス仕様、利用可能なオプション、契約条件は別途確認する必要があります。