單機服務器支持千萬級併發長鏈接的壓力測試

很早之前就據說了c10k，c100k，c1000k等問題，每一個問題的解決都是併發編程的一個里程碑。隨着硬件的快速提高，那麼10m（千萬）併發鏈接呢？可否作到？如何作到？會有什麼限制？小編對此很好奇，折騰了很多時間，終於有了使人興奮的答案！
下面咱們使用https://github.com/yedf/handy庫自帶的例子程序，來跑出一個單機千萬併發鏈接的實例，先上操做步驟，後面解釋。

準備機器

10m鏈接，你們的我的電腦確定沒法知足要求，若是不是在大公司任職，弄個實際的物理機對你們是個奢望。那麼怎麼辦？我也面臨一樣問題。
如今的雲計算這麼發達，還能夠按小時計費，一小時的費用也就幾元，那就試試雲計算產品吧。小編先是在阿里雲上測試，但阿里雲的按需付費主機配置不高，費了很多時間，最終只跑到了3m個鏈接。阿里雲的不行，是主機的配置問題仍是程序的問題呢？爲了獲得最終的結論，我嘗試了其餘的雲產品，最終ucloud的雲主機給了我驚喜。

首先建立ucloud主機
ucloud主機（一共須要兩臺，一臺做爲服務器，一臺做爲客戶端）：
. 選擇主機管理的建立主機
. 系統選擇ubuntu14.4 64bit （小編的測試程序是c++11，須要高版本的g++）
. 機型標準版
. 網絡加強必定要選擇開啓 （千萬鏈接是網絡IO密集型，網絡固然要強大型）
. cpu 16核 內存64G 數據盤0
. 下一步中的網絡類型選擇基礎網絡便可，建立主機以後，須要購買彈性ip，而且綁定到主機
. 價格：小編實驗時（2015年8月），上述的配置，一臺僅需7.2元一小時，兩臺不到15元

作實驗的時候，你們記得要眼疾手快哦，一小時十幾元，得到了本身想要的結果就趕忙釋放主機哈

調整系統參數

10m併發鏈接對系統是個挑戰，須要調整相關的參數

sysctl -w fs.file-max=10485760 #系統容許的文件描述符數量10m
sysctl -w net.ipv4.tcp_rmem=1024 #每一個tcp鏈接的讀取緩衝區1k，一個鏈接1k
sysctl -w net.ipv4.tcp_wmem=1024 #每一個tcp鏈接的寫入緩衝區1k
#修改默認的本地端口範圍
sysctl -w net.ipv4.ip_local_port_range='1024 65535' 
sysctl -w net.ipv4.tcp_tw_recycle=1  #快速回收time_wait的鏈接
sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_timestamps=1
#用戶單進程的最大文件數，用戶登陸時生效
echo '* soft nofile 1048576' >> /etc/security/limits.conf 
echo '* hard nofile 1048576' >> /etc/security/limits.conf 
ulimit -n 1048576 #用戶單進程的最大文件數 當前會話生效

部署程序

下面能夠開始部署咱們的測試程序了

apt-get update
apt-get install -y screen git make g++ nload iptraf
git clone https://github.com/yedf/handy
cd handy
git checkout 97b5426f91d37
make -j4

運行測試程序

選取一臺主機S做爲服務器，運行服務器

10m/10m-svr 100 300 10 301 #啓動10個子進程，每一個進程分別監聽100-300的端口

選取另外一臺主機C做爲客戶端，運行客戶端，（須要填寫S的內網ip）

#啓動10個客戶端子進程，鏈接到S的100-300端口，發起10m個鏈接，在500秒內建立全部的鏈接，每600秒發送一個心跳，心跳數據爲64字節，多進程的管理端口爲301
10m/10m-cli <S> 100 300 10000000 500 10 600 64 301

觀察結果

而後，10m鏈接的創建就不須要更多的步驟啦，使用命令
watch ss -s
咱們就能夠開始觀察鏈接的建立進度啦，看着鏈接漸漸的往上走，超過10k，100k, 1m是否是頗有成就感。

說明

併發鏈接數到達千萬時，有諸多方面的問題須要解決：

. 單進程最大文件數量限制：limit -n 最多能把這個數字修改到1048575，所以單個進程最多可以打開百萬個文件，千萬併發鏈接須要千萬個文件描述符，因而咱們使用多進程來作到千萬文件的支持

.多進程之間的負載均衡：nginx使用多進程來增長本身的吞吐量，原先採用共享鎖的方式來平衡負載，對核數較多的服務器，較多的進程並無達到性能的線性提高。最新的linux內核引入了SO_REUSEPORT選項，該選項能夠自動平衡監聽同一端口的多進程，是內核級的解決方案。handy採用該方案，優於nginx的舊有方式（最新的nginx也支持SO_REUSEPORT）。

.測試中客戶端本地端口不夠：讓服務器監聽了200個端口，這樣客戶端鏈接服務器的每一個端口只有50k個鏈接，而後加大默認的本地端口範圍就能夠知足要求（見前面的服務器系統參數）

測試中若是一次性建立千萬個鏈接，則絕大部分的鏈接建立都會失敗，所以讓客戶端每100ms建立2000個鏈接，提升鏈接建立的成功率。

系統在運行中，並無多少的負載，固然啦，一部分負載跑到底層的hypervisor去了

小編實驗的機器上內存佔用大約40G，平均一個鏈接先後一共用了4k，很少很少

你們能夠經過iptraf，nload等工具來查看系統的網絡狀況

寫到這裏，順便給出我測是的ucloud主機的性能參數吧：
網卡流量最多能夠到1.2GBit/s，並不是全部時間都到了這麼高，並不穩定，通常在800M-1.2G之間波動
tcp收包發包的最高qps是12w/s，多了就上不去了

後續

爲了達到千萬條鏈接，折騰了很多問題，上面只是個大概，有些地方的細節並無深刻探討。若是你們有興趣，後續會慢慢把其餘細節分享出來。

 

--------2017-12-02更新測試結果-------

最近看見阿里推出了網絡加強型服務器，pps可以達到450w，因而拿handy的千萬鏈接進行了測試。在阿里雲上面，按量購買沒法購買到最高配的虛機，最高的只購買了下面機型：

網絡加強型，60w pps，16核，64G

命令以下

handy/10m/10m-svr 100 500 16 501 #服務器 handy/10m/10m-cli <S> 100 500 10000000 150 16 170 64 501 # 150s建立1千萬鏈接 

可以完成千萬條鏈接，達到的pps大約是20w，進一步增長網絡負載會致使必定程度丟包，這個qps與主機聲稱的60w差距較大，可能跟當時共享的機器有關

 

網絡加強型，100wpps，8核，32G

命令以下

handy/10m/10m-svr 100 500 16 501 #服務器 handy/10m/10m-cli <S> 100 500 6500000 30 16 40 64 501 # 30s 建立650w鏈接 

32G內存只到650w鏈接，達到的pps大約是65w，進一步增長網絡負載會致使必定程度丟包

 

handy的各個測試中，應用的性能都會隨着主機的性能提高而提高，瓶頸主要是在系統的內存和網卡IO處

你們若是有更高配的機型，而且有興趣測一測，歡迎你們把測試結果發給我，合併到本文的結果中