异数OS TCP协议栈测试（五）--关于QOS与延迟
.
异数OS TCP协议栈测试（五）–关于QOS与延迟
##本文来自异数OS社区
github： https://github.com/yds086/HereticOS
异数OS社区QQ群： 652455784
异数OS-织梦师（消息中间件 ，游戏开发方向）群： 476260389
异数OS-织梦师-Xnign（Nginx方向）群： 859548384
关于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上，因此还能正常低延迟访问。
wrk linux 无优化环境压测
压测客户端为千兆网卡，linux环境，内网无丢包，成绩大概2线程 9W QPS,120us平均延迟，该测试主要被linux本身性能约束，并不反映Xnign服务端的最大性能容量，实际上wrk 16CPU核16线程压测Xnign时，异数OS CPU占用率仅3%，而此时linux wrk已16核满载，成绩却下降到1W QPS,反复测试几次后linux wrk出现无法响应问题，杀掉进程重启wrk任然无响应，netstat显示无异常链接，此时windows浏览器任然可以打开页面，XnignTest压测任然正常，由于异数OS作者并不懂linux 优化，所以测试没有再继续深入，wrk使用保持长连接，短链接由于TIME_WAIT状态问题所以没有参考意义，请求数达到28231后wrk停止响应。
linux wrk异常后windows浏览器的反馈。
82599网卡4%丢包环境测试
下面两项为82599网卡4%丢包环境测试, 4%丢包可以用于模拟广域网高延迟高错误的情况，更能挑战反应协议栈以及上层应用的容错能力，稳定性，通讯延迟，链接活跃保持能力等，压测端使用XnignTest。
XnignTest压测 2W保持链接
196W QPS ，平均10ms，最小40us,正态分布统计99%在115ms中完成，超出400ms以上IO延迟约占0.15%
XnignTest压测 1链接
该测试用于直观分析单个链接的性能表现，可以看到大概1000QPS，平均1ms，最小10us，最大100ms。
这两项82599 4%丢包环境测试可以看到Xnign任然保持着0错误和100%的链接活跃可用，当然QPS性能损失还是有，20000链接时损失20%的性能从230WQPS下降到190W左右，单链接QPS性能则从10W QPS下降到1000，但即便是低延迟要求的游戏而言1000的QPS，100ms最大延迟平均1ms延迟也是完全够用的。
