異數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上，因此還能正常低延遲訪問。
82599網絡卡4%丟包環境測試
4%丟包可以用於模擬廣域網高延遲高錯誤的情況，更能挑戰反應協議棧以及上層應用的容錯能力，穩定性，通訊延遲等。
wrk linux 無優化環境壓測
9W QPS,200us平均延遲，該測試主要被linux本身效能約束，並不反映服務端的最大效能容量，實際上wrk 16CPU核16執行緒壓測Xnign時，異數OS CPU佔用率僅3%，而此時linux wrk已16核滿載
XnignTest壓測 2W保持連結
186W QPS ，平均10ms，最小40us
XnignTest壓測 1連結
4000QPS，平均1ms，最小10us，最大100ms
