异数OS TCP协议栈测试（五）--关于QOS与延迟

异数OS TCP协议栈测试（五）–关于QOS与延迟

##本文来自异数OS社区

github： https://github.com/yds086/HereticOS

异数OS社区QQ群： 652455784

异数OS-织梦师（消息中间件，游戏开发方向）群： 476260389

异数OS-织梦师-Xnign（Nginx方向）群： 859548384

文章目录

异数OS TCP协议栈测试（五）--关于QOS与延迟

@[toc]

关于TCP QOS以及延迟基本理论

Xnign延迟测试方案

异数OS软件交换机平台理论延迟测试

82599网卡4%丢包环境测试

wrk linux 无优化环境压测

XnignTest压测 2W保持链接

XnignTest压测 1链接

关于TCP QOS以及延迟基本理论

本文讲述的是echo模式下的IO延迟与QOS，延迟是个比较敏感的话题，这也是异数OS直到今天才放出具体延迟数据的原因，因为这需要一个具体的业务场景才可以描述清楚延迟是什么，所以当Xnign稳定的提供服务后，我们才开始做具体的更有意义的延迟测试，Xngin是一个httpserver,因此延迟的理论计算很直白很简单，下面是延迟理论计算公式。
1.通常情况下，系统为所有并发服务提供均衡请求时(linux C10K时无法稳定提供)
平均延迟=（系统并发连接数量 /QPS） +（系统链路延迟）.
2.当系统有QOS质量控制的情况下(linux无法提供)
平均延迟=（QOS队列中IO数量/QPS） +（系统链路延迟）.
3.异数OS则在提供以上两种延迟方式基础上提供第三种延迟模式(linux无法提供)
最小延迟=（业务响应延迟/QPS） +（系统链路延迟） .
除去系统链路延迟（网卡交换机路由延迟），第一第二种模式，延迟都与系统并发数以及系统能够提供的QPS性能有直接关系，而第三种模式典型的业务响应延迟数值上可以认为是1，因此无论连接数量多少，都可以提供1/QPS的延迟，该模式可在海量链接时任然提供低延迟体验，这一方案唯有异数OS平台可提供，数据没有上，明白的私聊。

关于Xnign的实现以及测试代码可以在社区群共享获得。

Xnign延迟测试方案

异数OS软件交换机平台理论延迟测试

1.我们在system2启动两个容器，并分别启动Xnign服务，容器1 ip=192.36.0.51 qos=1,容器2 ip =192.36.0.101 qos=2,命令如下
S2-C1: (list (StartService Xnign “-qosid=1”) )
S2-C2: (list (StartService Xnign “-qosid=2”) )
2.在system4启动两个容器，其中容器2启动4个命令控制模式XnignTest，分别对应链接不同qos下的两个Xnign，命令如下
S4-C2: (list (StartService XnignTest “-dip=192.36.0.51 -qosid=1 -ctl”))
S4-C2: (list (StartService XnignTest “-dip=192.36.0.51 -qosid=2 -ctl”))
S4-C2: (list (StartService XnignTest “-dip=192.36.0.101 -qosid=1 -ctl”))
S4-C2: (list (StartService XnignTest “-dip=192.36.0.101 -qosid=2 -ctl”))
创建的服务：
在这里插入图片描述

3.测试两个Xnign的延迟，
S4-C2: (ServiceInput 1 “-pc=10 -lp -start”)
S4-C2: (ServiceInput 1 “-pc=10 -sp -start”)
S4-C2: (ServiceInput 3 “-pc=10 -lp -start”)
S4-C2: (ServiceInput 3 “-pc=10 -sp -start”)
结果：
在这里插入图片描述

延迟数据单位为ns，可以看出长连接平均延迟为1us,短连接平均延迟2.5us，注意由于我们开启了两个Xnign并占用两个Qos队列，因此当system上只有一个Xnign时，延迟测试数据只有该数据一半左右，另外延迟统计算法大概占用200ns左右没有剔除。

给ip=192.36.0.51 qos=1的Xnign服务一个100W并发长链接的循环压测测试
S4-C1: (list (StartService XnignTest “-dip=192.36.0.51 -c=1000000 -qosid=1”))

100W长链接循环压测，平均延迟570ms。

5.回到S4-C2，再分别测试下两个Xnign的服务延迟
S4-C2: (ServiceInput 1 “-pc=10 -lp -start”)
S4-C2: (ServiceInput 1 “-pc=10 -sp -start”)
S4-C2: (ServiceInput 2 “-pc=10 -lp -start”)
S4-C2: (ServiceInput 2 “-pc=10 -sp -start”)
S4-C2: (ServiceInput 3 “-pc=10 -lp -start”)
S4-C2: (ServiceInput 3 “-pc=10 -sp -start”)
S4-C2: (ServiceInput 4 “-pc=10 -lp -start”)
S4-C2: (ServiceInput 4 “-pc=10 -sp -start”)
得到结果：
在这里插入图片描述
可以看出由于100W压测链接影响，S2-C1的Xnign服务器延迟已经比较高了，其中短连接几乎测试失败，长连接则稳定在确定的570ms延迟上，而S2-C2的Xnign由于在Qos2上，因此还能正常低延迟访问。