
特定の輻輳アルゴリズムが機能しているかどうかをどのようにテストしますか? ほとんどのアルゴリズムの代表的なワークロードを簡単に再現できるわけではないので、質問します。
現在、2 つのことを検討していますが、他の提案も歓迎します。
- 出力から「再送信されたセグメント」
netstat -s
私の現在の考えでは、輻輳により一定の割合でパケットがドロップされる可能性があるため、ドロップされるパケットとサーバーに輻輳イベントが通知されることの間に 1:1 の関係はないかもしれませんが、あるアルゴリズムに切り替えることでドロップされるパケットが少なくなる場合は、緩やかな相関関係があると考えられます。
この数字は、輻輳により再送信されたセグメントを示しているのでしょうか、それとも損失リンクに限定されているのでしょうか? もしそうなら (そして私はそうかもしれないと思っています)、それは状況をさらに混乱させ、これが使用するのに適切な指標ではないという点にまで至る可能性があります。
- TCP 接続の平均経過時間を測定するのに使用できるメトリックはありますか?
ここでの私の考えは、TCP 接続が早く終了する (エラーの急増やパケットのドロップがない場合) ということは、データが少ない遅延でプッシュされていることを示している可能性があるということです。
答え1
この数字は、輻輳により再送信されたセグメントを示しているのでしょうか、それとも損失リンクに限定されているのでしょうか? もしそうなら (そして私はそうかもしれないと思っています)、それは状況をさらに混乱させ、これが使用するのに適切な指標ではないという点にまで至る可能性があります。
segments retransmitted
これにはnetstat -s
、質問に記載されている理由も含め、あらゆる理由によるカーネルの TCP 再送信がすべて含まれます。これらの理由には、次のようなものも含まれる可能性があります。
- リンクエラー
- イーサネットスイッチの輻輳
- QoS またはリソースの枯渇によりローカル ホストがドロップする
- リモート ホストのドロップ (リモート ホスト上の何らかの QoS/リソースの枯渇が原因と考えられます)
パフォーマンス テスト エンジニアは、これらすべての変数を日常的に処理し、適切に測定できるようにします。最初に行うべきテストの 1 つは、問題となっているパケット サイズとトラフィック レートでケーブル/ネットワークが正常に動作していることを確認することです。これは通常、Ixia や Spirent などの専用テスト アプライアンスを使用して行われます。
ネットワーク パフォーマンスのベースラインを設定したら、必要なテストを実行できます。ネットワークのテスト結果が正常であったとしても、ホスト TCP テスト中にスイッチ インターフェイスのエラーやドロップを監視して、結果が歪んでいないことを確認する必要があります。
輻輳状態の作成に関するお考えについては、TCP トラフィックを実行する前に、意図的に QoS クラスのキューイングしきい値よりわずかに低い iperf UDP バックグラウンド トラフィックを生成すると役立つ場合があります。リンクを飽和させることができない場合は、NIC を 1GE または 100M にネゴシエートすると役立つ場合もあります。
これらはすべて複雑に聞こえるかもしれませんし、ある意味では確かに複雑かもしれません。しかし、すべてのシステム コンポーネントに適切な焦点と可視性があれば、QoS テストは完全に実行可能です。
答え2
簡潔版:
@ninjalj が指摘したように、特定の調整がワークロードのパフォーマンスに有益であったかどうかについては、ワークロード アプリケーションが信頼できる情報源であると考えられます。要件がレイテンシであるか、システム全体のスループットのみであるかに応じて、動作の変更がパフォーマンス要件をよりよく満たすかどうかを判断できます。
この場合、変更を加えて、httpd
の全体的なレイテンシが低下したかどうかを確認します。
具体例を挙げた長いバージョン:
詳しく説明するために、これを文脈に沿って説明します。Apache を見てみましょう。およびディレクティブhttpd
を使用して、リクエストを完了するまでの時間をマイクロ秒単位で記録し、各リクエストのサイズを記録できます。たとえば、次のようになります。LogFormat
CustomLog
LogFormat "%h %m %D %b" perflog
CustomLog /var/log/httpd/performance.log perflog
次のような出力が生成されます。
xxx.xxx.28.20 GET 41140 86
xxx.xxx.28.20 GET 34468 28
xxx.xxx.28.20 GET 47612 1434
xxx.xxx.28.20 GET 54860 868
xxx.xxx.28.20 POST 97055 6283
xxx.xxx.28.20 GET 33754 53
xxx.xxx.28.20 GET 68964 8416
xxx.xxx.28.20 GET 1143827 11528
xxx.xxx.28.20 GET 38055 61
xxx.xxx.64.208 HEAD 6255 -
xxx.xxx.28.20 GET 36922 142
xxx.xxx.28.20 GET 51871 5581
GET
私はこれについてのリクエストにだけ関心を持ちます:
root@xxxxxxvlp14 /tmp $ grep GET /var/log/httpd/performance.log > work.log
root@xxxxxxvlp14 /tmp $ sed -i 's/-$/0/g' work.log
root@xxxxxvlp14 /tmp $
(何らかの理由で、httpd
整数 0 の代わりにハイフンが与えられます)。
次に、プログラムでそれを分解します。
#!/bin/bash
totalRequests=$(cat /tmp/work.log | wc -l )
totalTime=$(awk 'BEGIN{ count=0 } {count = count + $3} END { print count }' /tmp/work.log)
averageTime=$( printf "%.2f" $(bc -l <<< "$totalTime / $totalRequests "))
minTime=$(sort -nk 3 work.log | head -1 | awk '{print $3}')
maxTime=$(sort -rnk 3 work.log | head -1 | awk '{print $3}')
totalBytes=$(awk 'BEGIN{ count=0 } {count = count + $4} END { print count }' /tmp/work.log)
minBytes=$(sort -nk 4 work.log | head -1 | awk '{print $4}')
maxBytes=$(sort -rnk 4 work.log | head -1 | awk '{print $4}')
echo "Total Requests In Sample: $totalRequests"
echo
echo "Total Time Taken: $totalTime ms (average: $averageTime ms)"
echo "Longest Request: $maxTime ms"
echo "Shortest Request: $minTime ms"
echo
echo "Total Data Moved: $totalBytes bytes"
echo "Largest Request: $maxBytes bytes"
echo "Smallest Request: $minBytes bytes"
スクリプトについてはコメントしないでください。効率性ではなく明確さのために書かれています。上記の結果は次のようになります。
Total Requests In Sample: 207
Total Time Taken: 15138613 ms (average: 73133.40 ms)
Longest Request: 1143827 ms
Shortest Request: 1788 ms
Total Data Moved: 409825 bytes
Largest Request: 20476 bytes
Smallest Request: 0 bytes
明らかに、上記は長いサンプルを取得することがなぜ重要であるかを示しています。ただし、数字は正確です (1 分半の長さのリクエストは、画像やグラフを含む Word 形式のレポートを生成するためのものでした)。
したがって、Apache に通常のアクティビティの長いサンプル (おそらく 1 日中) を提供するように依頼し、変更を加えてログをローテーションし、その後、再びログの収集を開始します (たとえば、さらに 24 時間待機します)。
各サービス(NFS、他のHTTPサーバー、Samba、FTPサーバーなど)は独自の方法で情報を収集しますが、一般的にはいくつかの時間とスループットを記録する手段。