特定の輻輳アルゴリズムがあなたに適しているかどうかをテストする方法は？ほとんどのアルゴリズムの代表的なワークロードを簡単に再現できないようで、この質問をします。
現在検討中の2つのことがありますが、より多くの提案を受けたいと思います。
- 出力の「再送信されたセグメント」
netstat -s
現在の私の考えは、輻輳のために一定の割合でパケットがドロップされる可能性があることです。したがって、破棄されたパケットと輻輳イベントの通知を受け取るサーバーとの間に1：1の関係がない可能性がありますが、緩い相関関係がある可能性があります。アルゴリズムに切り替えると、パケット損失が減少します。
グラフには、輻輳によって再送信されるセグメントが表示されますか、それとも損失のあるリンクに制限されていますか？もしそれが本当なら（私の考えではそうかもしれません）、状況はおそらくこれが非常に良い尺度ではないほど混乱しているでしょう。
- TCP接続の平均寿命を測定するために使用できる指標はありますか？
私の考えでは、TCP接続が早く完了した場合（エラーの急増やパケットの削除なし）、データが短い待ち時間でプッシュされていることを示すことができます。
ベストアンサー1
グラフには、輻輳によって再送信されるセグメントが表示されますか、それとも損失のあるリンクに制限されていますか？もしそれが本当なら（私の考えではそうかもしれません）、状況はおそらくこれが非常に良い尺度ではないほど混乱しているでしょう。
segments retransmittednetstat -sあなたの質問にリストされているものを含め、何らかの理由ですべてのカーネルTCP再送信を含めます。この理由には、次のものも含まれる場合があります。
- リンクエラー
- イーサネットスイッチの輻輳
- Qosまたはリソースの枯渇により、ローカルホストがオフラインになりました。
- リモートホストがオフラインになります（リモートホストのqos /リソース枯渇が原因である可能性があります）。
パフォーマンステストエンジニアは通常、これらすべての変数を処理し、適切に測定できることを確認します。最初に実行する必要があるテストの1つは、ケーブル/ネットワークが関連するパケットサイズとトラフィックレートで正しく実行されていることを確認することです。これは通常、イクシアやスピレントの機器などの特別なテスト機器を使用して行われます。
ネットワークパフォーマンス基準を設定したら、必要なテストを実行できます。ネットワークテストがきれいであっても、ホストTCPテスト中にスイッチインターフェイスのエラー/削除を監視し、結果が歪んでいないことを確認する必要があります。
輻輳条件を作成することを考えると、TCPトラフィックを実行する前に、qosクラスキューのしきい値のすぐ下にiperf UDPバックグラウンドトラフィックを意図的に生成することが役立ちます。既存のリンクを飽和させることができない場合は、NICを1GEまたは100Mに下げることも役立ちます。
これらすべてが複雑に聞こえるかもしれませんし、ある意味ではそうです。ただし、すべてのシステムコンポーネントに対する適切な注意と理解により、QoSテストは完全に可能です。