☰

測試擁塞演算法是否成功

tag-icon • tag-icon networking linux-kernel performance
測試擁塞演算法是否成功

如何測試特定的擁塞演算法是否適合您？我問這個問題是因為我似乎無法輕鬆地為大多數演算法重新創建具有代表性的工作負載。

我目前正在考慮兩件事，但我願意接受更多建議：

  • 輸出中的“重傳的段落”netstat -s

我目前的想法是，擁塞可能會導致資料包在一定比例的時間內被丟棄，因此，雖然被丟棄的資料包與收到擁塞事件通知的伺服器之間可能不存在1:1 的關係，但可能存在鬆散的相關性如果切換到一種演算法導致丟包更少，則繪製。

該圖是否顯示了由於擁塞而重傳的資料段，或者是否僅限於有損鏈路？如果是這樣（我認為可能是這種情況），情況可能會更加混亂，以至於這不是一個很好的衡量標準。

  • 是否有可用於測量 TCP 連線平均壽命的指標？

我的想法是，較早完成的 TCP 連線（沒有錯誤和丟棄資料包的峰值）可能表明資料正在以較小的延遲推送。

答案1

該圖是否顯示了由於擁塞而重傳的資料段，或者是否僅限於有損鏈路？如果是這樣（我認為可能是這種情況），情況可能會更加混亂，以至於這不是一個很好的衡量標準。

segments retransmittedinnetstat -s包括出於任​​何原因的所有核心 TCP 重傳，包括您的問題中列出的那些。這些原因也可能包括：

  • 連結錯誤
  • 乙太網路交換器擁塞
  • 本機因 qos 或資源耗盡而斷線
  • 遠端主機斷線（可能是由於遠端主機上某種形式的 qos/資源耗盡）

性能測試工程師通常會處理所有這些變量，並確保他們可以適當地測量它們。您應該做的首要測試之一是確保佈線/網路在相關資料包大小和流量速率下運作乾淨。這通常使用專用測試設備來完成，例如 Ixia 或 Spirent 的測試設備。

一旦確定了網路效能基線，您就可以執行您所要求的測試。即使網路測試乾淨，您仍然應該在主機 TCP 測試期間監視交換器介面錯誤/丟棄，以確保它們不會扭曲您的結果。

至於您對建立擁塞條件的想法，您可能會發現在運行 TCP 流量之前有意產生略低於 qos 類別排隊閾值的 iperf UDP 後台流量很有幫助。如果您發現無法使現有連結飽和，您可能還會發現將 NIC 降低至 1GE 或 100M 會有所幫助。

所有這些聽起來可能很複雜，在某些方面也許確實如此。然而，只要適當關注並了解所有系統組件，QoS 測試是完全可行的。

答案2

簡潔版：

正如 @ninjalj 指出的那樣，工作負載應用程式可能應該被視為任何給定調整是否有利於工作負載效能的權威來源。根據您的要求是延遲還是系統的整體吞吐量，您可以判斷行為的變化是否可以更好地滿足您的效能要求。

在這種情況下，它將進行更改並注意httpd整體延遲是否下降。

帶有具體範例的較長版本：

為了詳細說明，我將把它放在上下文中。讓我們看看阿帕契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

顯然，上面的內容說明了為什麼獲取長樣本很重要。不過，這些數字是正確的（這個一分半鐘的請求是有人產生了一份 Word 格式的報告，其中包括圖像/圖表，以滿足好奇心）。

因此，您會哄騙 apache 為您提供正常活動的冗長樣本（可能在一整天的過程中），進行更改，輪換日誌，然後再次開始收集日誌（例如，等待另一個 24 小時）。

每個服務（NFS、其他 HTTP 伺服器、Samba、FTP 伺服器等）都有自己的收集資訊的方式，但通常會有一些記錄時間和吞吐量的方法。

相關內容