☰

测试拥塞算法是否成功

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 服务器等）都有自己的收集信息的方式，但通常会有一些记录时间和吞吐量的方法。

相关内容