.net core百萬設備鏈接服務和硬件需求測試

隨着物聯網的普及,服務應用將面對大量物聯設備處理;早期.NET在通信上的處理能力一直給人的印像並不怎樣,但net core經歷過大量的優化後在各個模塊的處理性能都有着比較出色的提高,針對網絡方向的處理模塊也有着顯著的提高。如下主要測試.net core在不一樣鏈接數據併發下的資源吏用狀況,用於評估在不一樣數量鏈接上服務的處理能力和硬件配置的需求。javascript

測試描述

分別以200,10萬,50萬,100萬不一樣鏈接數下接收數據包和響應的資源使用狀況,200鏈接狀況下經過響應請求方式進行高吞吐壓測,後面則模擬設備每10秒發送一個數據包。發送數據以下:java

000000123,0002123,00001234,20190430093022,01,020

以上簡單地模擬一個設備信息,主要包括ID,座標,時間和狀態信息等,服務端接收後分解消息並返回。服務端處理代碼以下:nginx

public override void SessionReceive(IServer server, SessionReceiveEventArgs e) { base.SessionReceive(server, e); var stream = e.Stream.ToPipeStream(); while (stream.TryReadLine(out string line)) { string[] properties = line.Split(','); stream.WriteLine(line); e.Stream.Flush(); } } 

測試環境

  • 操做系統
window 2008 server 
  • 運行環境
dotnet core 2.1 
  • 硬件資源
CPU E3-1230V2 16G內存 10Bb網絡 
  • 測試工具
Tcp TCPBenchmarks https://github.com/IKende/TCPBenchmarks 

200鏈接

在小鏈接的狀況其吞吐能力仍是很是出色的,在這臺PC上達到30萬rps的狀況還沒徹底把CPU跑滿。git

10萬鏈接

 

測試結果來看,平均併發在10000RPS;大部分請求都能在5ms內響應完成,而程序大部分工做時間CPU在10%之內,內存佔用大概700MB。github

50萬鏈接

測試結果來看在50萬在線的時候,平均併發在100000RPS;大部分請求一樣在5ms內響應完成,程序大部分工做時間的CPU在20%之內,內存佔用大概在3.5G服務器

100萬鏈接

100萬在線的時候,平均併發在100000RPS;大部分請求一樣在100ms內響應完成,程序大部分工做時間的CPU在40%之內,內存佔用大概在7-9G.不過此次測試的延時相對比較高,因爲負載量的狀況測試端也會引發延時的問題,因此致使總體延時比較高。網絡

總結

以上測試的服務器的CPU比較舊,已是6年前的老產品,但在這個CPU的支持下運行100萬鏈接處理也不算存在壓力。其主要緣由仍是總體的RPS並不高,當在100萬鏈接的狀況吞吐值在10萬RPS;這樣也能夠說明在網絡服務中佔CPU資源的是請求的響應量而不是在線的鏈接數,不過當在線鏈接數比較多的狀況仍是須要佔用大量的內存;因此在制是定硬件規劃的時候能夠針對在線鏈接數和請求量進行一個結合規劃。併發

相關文章
相關標籤/搜索