異數OS TCP協議棧測試（三）--長鏈接篇

異數OS TCP協議棧測試（三）--長鏈接篇

本文來自異數OS社區

 

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

異數OS社區QQ羣：  652455784

異數OS-織夢師（消息中間件）羣： 476260389

 

異數OS TCP長鏈接技術簡介

提及長鏈接，則首先要談對C10K的理解與認識，異數OS認爲傳統系統中C10K問題主要以下：

1. 傳統OS 線程切換代價很大，線程資源有限（500以上可用性下降），這使得多線程阻塞IO性能達到1W時，線程切換將佔滿系統負載，應用併發session數量則被系統線程數量約束，但多線程阻塞IO這種模式對應用邏輯設計而言倒是自然簡單友好靠譜的，而異數OS線程切換能力爲80M, 1億線程4G內存，也不會下降太多線程切換能力以及IO能力， 因此使用這種方案。

2. 爲了不線程切換以及線程資源不夠帶來的問題，主流操做系統使用隊列技術(iocp epoll)來批量成倍提高IO性能，每次線程切換完成10個甚至數百個IO操做或者event推送，使用異步技術來讓單個線程管理多個session的能力，因此表面上看提升了併發容量，但這類技術卻大大下降了併發質量反而形成了更嚴重的C10K問題，使用這一技術，每一個連接必需要提供中間傳輸緩存，連接多了後，IO需求大時，隊列會很長，延遲會很高，加劇了系統負擔，因爲這類技術都是非阻塞異步IO,不能較好的阻塞session應用邏輯，所以沒法爲每連接作可靠的業務流程控制以及QOS控制，連接多了，就會有餓死的連接，出現大量錯誤IO，相對多線程阻塞IO模式，雪崩問題更加嚴重。

3. TCP協議棧沒有爲海量連接作優化，其常見的流控擁塞算法都只針對連接自身的IO性能，並不考慮上層應用實際需求，以及其餘連接的IO需求，在這種狀況下TCP檢查網絡擁塞的算法將沒有任何意義，實際測試發現若是每連接IO不作控制，1000連接都很難上去，正確的作法是將擁塞控制算法提升到系統層以及應用層由系統QOS任務調度以及應用需求共同來實現。

4. 協議棧中間緩存太多，拷貝動做較多,傳統OS每連接協議棧須要4K以上內存，實作一個1000W連接的系統通常要60G內存起步，這直接增長了系統負載，下降了系統可用性。

5. 協議棧IO性能不足，因爲傳統操做系統IO性能約束，實作的協議棧只能提供10-40W的IO性能，而且不能多核擴充，IO過載時會，協議棧會出現無響應丟包現象，丟包後協議棧性能需求會更高，能提供的IO性能會大大下降，若是應用不能適應這種IO性能變化，將會製造更多的中間緩存，致使雪崩，在這樣的狀況下，作1000W連接的應用可用性會受到極大的限制，好比微信使用這一類技術就只能用於心跳連接活躍檢查。

 

一些號稱實作了C10M的技術方案從本質上沒有解決上述問題，僅僅靠硬件技術堆硬件配置來表面實現，但實際上卻沒有任何可用性。

異數OS TCP長鏈接技術演變

2015年，異數OS考慮開始使用海量線程同步阻塞IO的方案來解決iocp不能作QOS,隊列過長的問題，異數OS使用任務調度來控制每連接的IO提交性能需求，並智能感知雪崩狀況的發生，動態控制IO性能以及應用提交的中間緩存規模，從而減小了中間緩存開銷，下降了海量併發下iocp隊列深度，下降對宿主操做系統的負載壓力，從而實現了1000W連接12W的消息推送性能。

 

2017年，因爲發現宿主操做系統協議棧的能力約束，異數OS決定拋棄宿主操做系統協議棧，以及IO技術，開始自主研發TCP協議棧，實作0中間緩存，1次中間拷貝的技術，從而達到每連接300字節佔用，併發容量相對異數OS 2015,提升15倍，IO性能提高100倍，且能夠多核擴充，大大提升了海量併發環境的系統可用性。

 

 

測試目標

 

TCP 長連接IO性能測試，Client Server都採用單線程半雙工模式，建立600W客戶端（本機測試至關於1200W連接），連接服務端後作循環ECHO,測試ECHO IO性能，IO延遲，每連接性能穩定性。

 

 

基本測試環境

VMware 12

異數OS宿主操做系統 debian 8 64位

CPU : NUC i3 2.6G 雙核

內存:5GB

 

相關參數

1. 帶包頭200字節負載，不帶crc checksum, 無丟包,無硬件延遲狀況。

2.  TCP協議棧使用均衡IO調度策略。

測試方案一 (單核)

在同一個CPU核上建立Server,600W個Client, 以太層使用異數OS軟件交換機本地核定向轉發。

 

啓動前期：

 

 

啓動後期（2個多小時後）：

 

 

總計ECHO IOPS 爲2.3M ,軟件交換機包交換能力9Mpps，因爲Client佔用60%的負載，軟件交換機佔用20%負載，因此預計真實環境中最大可達到6.0M左右的ECHO能力，IO延遲方面，在系統啓動階段因爲大量連接的創建，每連接IO需求不穩定，系統QOS IO均衡並無顯著的發生做用，平均延遲達到了2秒，一些連接任然有飢餓現象，出現上百秒才響應的狀況，在穩定連接後期,每連接IO需求穩定後，IO延遲降低，飢餓現象獲得緩解，但仍是有10s延遲的連接出現。

 

 

總結

因爲只使用了TCP協議棧的任務均衡調度控制方案，所以每連接IO質量在應用負載不均的狀況下仍是不能獲得及早的控制，這個問題後面會由應用系統的QOS來解決，好比mqtt等專業的APP QOS控制,下面是幾種主流系統的海量連接平臺能力性能對比，數據來自官網以及第三方測試，可比性可能不高，但也可作參考估算，讀者若有其餘海量併發的技術測試也歡迎提供

 

 

對比項目	異數OS 2018	異數OS 2015+Win7	異數OS 2015+Win10	360push	Whatsapp
CPU佔用數量	1	16	16	24	12
內存佔用	4G	64G	64G	256G	128G
實現的連接數	1200W	1000W	300W	100W	300W
使用的技術平臺	寄宿Linux下+異數自主協議棧	寄宿win下+iocp	寄宿win下+iocp	Go+epoll	Erlang+epoll
測試內容	ECHO 推拉	僅推	僅推	僅推	僅推
推送性能	4.5M	12W	40W	2W	12W
折算的IO性能	9M	12W	40W	2W	12W
已知問題	缺少經費支持	缺少經費支持	缺少經費支持	容易宕機，要反覆重啓	特製應用平臺，不一樣用。