Taurus.MVC 性能壓力測試(ap 壓測 和 linux 下wrk 壓測):.NET 版本

来源:https://www.cnblogs.com/cyq1162/p/18135830
-Advertisement-
Play Games

上次發佈了:Taurus.MVC 性能壓力測試(ap 壓測 和 linux 下wrk 壓測):.NET Core 版本,今天計劃準備壓測一下 .NET 版本,來測試並記錄一下 Taurus.MVC 框架在 .NET 版本的性能,以便後續持續優化改進。 為了方便對比,本文章的電腦環境和測試思路,儘量和... ...


前言:

上次發佈了:Taurus.MVC 性能壓力測試(ap 壓測 和 linux 下wrk 壓測):.NET Core 版本

今天計劃準備壓測一下 .NET 版本,來測試並記錄一下 Taurus.MVC 框架在 .NET 版本的性能,以便後續持續優化改進。

為了方便對比,本文章的電腦環境和測試思路,儘量和上文保持一致,以便方便對比。

下麵來看不同場景下的壓測結果,以下測試結果會由兩臺電腦進行分別測試。

一、舊電腦環境:

CPU :Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz
內核: 6
邏輯處理器: 6
記憶體:16G

程式在 .NET4 編繹,以 Windows 11 為主機直接運行在 IIS 環境:

1、測試 Window 11 下,單機ab工具壓測:

仍然先用ab工具,進行本機壓測,試試水。

ab的版本信息不變:

A、先測試單線程的運行性能(簡單介面返回):

ab -n 100000 -c 1 http://192.168.100.102:51996/api/hello

測試結果:併發數1,qps =  2293  【對比:.NET Core 8 對應的 qps = 3595】

Server Software:
Server Hostname:        192.168.100.100
Server Port:            51997

Document Path:          /api/hello
Document Length:        24 bytes

Concurrency Level:      1
Time taken for tests:   4.361 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      1190000 bytes
HTML transferred:       240000 bytes
Requests per second:    2293.29 [#/sec] (mean)
Time per request:       0.436 [ms] (mean)
Time per request:       0.436 [ms] (mean, across all concurrent requests)
Transfer rate:          266.51 [Kbytes/sec] received

由於是IIS運行,程式里沒預設列印時間,這裡無法看到單次執行的時候,沒法給出一個100萬+的美好理論推理值。

B、我們調整一下參數,看看ab在單機下能壓出多少來(簡單介面返回):

ab -n 100000 -c 4 http://192.168.100.102:51996/api/hello

測試結果:qps = 6277 【對比:.NET Core 8 對應的 qps = 5765】

Document Path:          /api/hello
Document Length:        24 bytes

Concurrency Level:      8
Time taken for tests:   1.593 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      1190000 bytes
HTML transferred:       240000 bytes
Requests per second:    6277.48 [#/sec] (mean)
Time per request:       1.274 [ms] (mean)
Time per request:       0.159 [ms] (mean, across all concurrent requests)
Transfer rate:          729.51 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       1
Processing:     0    1   0.4      1       3
Waiting:        0    1   0.4      1       3
Total:          1    1   0.4      1       4

Percentage of the requests served within a certain time (ms)
  50%      1
  66%      1
  75%      1
  80%      2
  90%      2
  95%      2
  98%      2
  99%      2
 100%      4 (longest request)

ab 在.NET8 中只能在2個併發中測試出5765的成績,而在.NET4 中能在8個併發中測試出6277的成績。

我懷疑是不是我調整了程式引發的,於是重新對.NET8進行測試:

測試結果顯示,數據一樣,這~~~~

C、使用 CYQ.Data 讀資料庫,輸出 Json,來看看壓測結果(讀資料庫介面)

測試代碼:

複製代碼
public void HelloDb(string msg)
{
    string conn = "server=.;database=MSLog;uid=sa;pwd=123456";
    using (MProc proc = new MProc("select top 1 * from SysLogs", conn))
    {
        Write(proc.ExeJson());
    }
}
複製代碼

運行結果:返回一條數據:

下麵直接進行壓測

ab -n 10000 -c 8 http://192.168.100.100:51997/api/hellodb

壓測結果:併發數 8 ,qps = 6031 【對比:.NET Core 8 對應的 qps = 5470】

Concurrency Level:      8
Time taken for tests:   1.658 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      10550000 bytes
HTML transferred:       9590000 bytes
Requests per second:    6031.36 [#/sec] (mean)
Time per request:       1.326 [ms] (mean)
Time per request:       0.166 [ms] (mean, across all concurrent requests)
Transfer rate:          6213.95 [Kbytes/sec] received

目前看來,在ab的測試結果中,倒是 .NET 程式在 Windows 部署中更優。

下麵用 wrk 進行極限壓測再看看結果:

2、測試 Window 11 下,虛擬機wrk工具壓測:(讀資料庫輸出Json)

虛擬機環境:

CPU :Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz
內核: 2
邏輯處理器: 2
記憶體:4G

分完虛擬機後,本機就剩下 4 核了,再去掉打開任務管理器,就占掉了10%的cpu,當個3核用了。

不過問題不大,儘管測就是了,為了保持介面的通用性,繼續使用讀資料庫輸出 Json 的介面:

先使用1線程1個鏈接測試試試水:

 wrk -t 1 -c1 -d 10s http://192.168.100.100:51997/api/hellodb

壓測發現一點反應都木有,直接卡死沒反應,經過反覆排查,發現是埠問題,不知為何,對該埠就是無法發起請求,鏈接超時。

更新 80 埠,重新測試,測試結果:qps = 1084  【對比:.NET Core 8 對應的 qps = 1518】

Running 10s test @ http://192.168.100.100/api/hellodb
  1 threads and 1 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     3.89ms   12.02ms 136.48ms   93.00%
    Req/Sec     1.11k   319.04     1.45k    81.44%
  10915 requests in 10.06s, 10.78MB read
Requests/sec:   1084.60
Transfer/sec:      1.07MB

不斷調整參數,來看看它的極限值:

wrk -t 2 -c 1024 -d 10 http://192.168.100.100/api/hellodb

測試結果:qps = 14171   【對比:.NET Core 8 對應的 qps = 23303】

Running 10s test @ http://192.168.100.100/api/hellodb
  2 threads and 1024 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    71.11ms   55.89ms 643.51ms   92.75%
    Req/Sec     7.57k     2.96k   15.56k    74.43%
  142731 requests in 10.07s, 140.86MB read
  Socket errors: connect 5, read 0, write 0, timeout 0
  Non-2xx or 3xx responses: 325
Requests/sec:  14171.14
Transfer/sec:     13.99MB

觀察測試 CPU 結果,程式占45%,資料庫和虛擬機占一半。

小結:

.NET 8 (qps = 23303,CPU 31%,Host = Kestrel )

.NET 4  (qps =14171,CPU 45%,host = IIS )

可以看出,在極限壓測試之下,.NET Core 比 .NET 的確是更少的資源,能同時處理更多的併發數。

下麵,我們換到新電腦上走走看,看新電腦有啥新突破沒有。

二、新電腦環境:

CPU    13th Gen Intel(R) Core(TM) i5-13600KF
內核:    14
邏輯處理器: 20
記憶體:64G

接下來,我們看看新電腦的表現如何,使用一樣的程式部署:Taurus.MVC + IIS + 本地 MSSQL2012。

A、先測試單線程的運行性能(簡單介面返回):

ab -n 100000 -c 1 http://192.168.100.102/api/hello

測試結果:併發數1,qps = 4399  【對比:.NET Core 8 對應的 qps = 11389】

Document Path:          /api/hello
Document Length:        24 bytes

Concurrency Level:      1
Time taken for tests:   22.728 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      11900000 bytes
HTML transferred:       2400000 bytes
Requests per second:    4399.90 [#/sec] (mean)
Time per request:       0.227 [ms] (mean)
Time per request:       0.227 [ms] (mean, across all concurrent requests)
Transfer rate:          511.32 [Kbytes/sec] received

B、我們調整一下參數,看看ab在單機下能壓出多少來(簡單介面返回):

ab -n 100000 -c 48 http://192.168.100.102/api/hello

測試結果:併發數48,qps = 19037【對比:.NET Core 8 對應的 qps = 18247】

Document Path:          /api/hello
Document Length:        24 bytes

Concurrency Level:      48
Time taken for tests:   5.253 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      11900000 bytes
HTML transferred:       2400000 bytes
Requests per second:    19037.81 [#/sec] (mean)
Time per request:       2.521 [ms] (mean)
Time per request:       0.053 [ms] (mean, across all concurrent requests)
Transfer rate:          2212.40 [Kbytes/sec] received

同樣 ab 壓不出結果,程式的cpu才跑了不到2%,倒是ab自身,占了快40%的cpu。

小結:

在新舊電腦測試中,ab 的最大壓測值(舊電腦:6277,新電腦:19037),同樣體現出是3倍左右的性能差異。

接下來,又到使用 wrk 使用壓限壓測試看看結果,沒錯,同樣測的是 wrk 的極限,不是程式的。

2、測試 Window 11 下,虛擬機wrk工具壓測:(簡單介面)

虛擬機環境:

CPU    13th Gen Intel(R) Core(TM) i5-13600KF
內核:    2
邏輯處理器: 2
記憶體:4G

先給虛擬機2核,本機剩下 12 核了,可以好好壓一下了。

wrk -t 1 -c 1 -d 10s http://192.168.100.102/api/hello

測試結果:1併發,qps = 4090【對比:.NET Core 8 對應的 qps = 14084】 

Running 10s test @ http://192.168.100.102/api/hello
  1 threads and 1 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   271.44us  530.73us  16.09ms   99.50%
    Req/Sec     4.11k   564.42     8.67k    93.00%
  40950 requests in 10.01s, 3.91MB read
Requests/sec:   4090.60
Transfer/sec:    399.47KB

和 ab 一樣,一個鏈接併發壓不出什麼效果,加大效果看看。

wrk -t 32 -c 2048 -d 10s http://192.168.100.102/api/hello

測試結果:qps = 36194 【對比:.NET Core 8 對應的 qps = 84306】 

Running 10s test @ http://192.168.100.102/api/hello
  32 threads and 2048 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    26.14ms   12.61ms 114.24ms   73.00%
    Req/Sec     2.30k   558.55     6.57k    71.40%
  365826 requests in 10.11s, 34.89MB read
  Socket errors: connect 1059, read 0, write 0, timeout 0
Requests/sec:  36194.23
Transfer/sec:      3.45MB

壓測試過程,觀察兩個cpu,虛擬機(110%-130%,2核還沒跑滿),程式跑了30%左右,整體40-50%左右,感覺還能往上跑。

估計是壓力不夠,試著分給虛擬機多2核,看看有沒有效果。

虛擬機環境:

CPU    13th Gen Intel(R) Core(TM) i5-13600KF
內核:    4
邏輯處理器: 4
記憶體:6G

繼續壓測試:

wrk -t 128 -c 2048 -d 60s http://192.168.100.102/api/hello

測試結果:qps = 47617【對比:.NET Core 8 對應的 qps = 105462】 

Running 1m test @ http://192.168.100.102/api/hello
  128 threads and 2048 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    53.05ms   64.23ms 891.51ms   87.32%
    Req/Sec   374.01     87.90     2.23k    73.18%
  2861819 requests in 1.00m, 763.30MB read
  Non-2xx or 3xx responses: 1245021
Requests/sec:  47617.29
Transfer/sec:     12.70MB

壓測試過程,觀察兩個cpu,虛擬機(200%-230%左右,跑滿2核多一點),程式跑了35%-40%左右,整體60-65%左右。

由於走完下麵的測試流程,重新回到此處,觀察測試結果有近50%的非正常狀態碼,所以重新壓測,降低參數,重新測試:

經過反覆壓測,找不回之前的結果了,我了和去,wrk 的參數,看來都是在隨機狀態下的隨機結果。

重覆壓的結果,是 wrk 上不去,cpu 也跑不上去,程式 cpu 也同樣跑不上去了,只好暫時採用這個值了,穩定的測試結果,個人覺得應該降10%-20%再取值。

重新壓測 CYQ.Data 讀資料庫轉Json輸出的介面(資料庫mssql2012 安裝在Window 11 本機):

介面的調用輸出:

進行壓測:

wrk -t128 -c 4096-d 60s http://192.168.100.102/api/hellodb

測試結果:qps = 45582【對比:.NET Core 8 對應的 qps = 73122】 

Running 1m test @ http://192.168.100.102/api/hellodb
  128 threads and 4096 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    86.07ms  109.54ms   1.99s    84.76%
    Req/Sec   357.79    106.70     2.61k    71.47%
  2739712 requests in 1.00m, 2.01GB read
  Socket errors: connect 0, read 0, write 0, timeout 66
  Non-2xx or 3xx responses: 1309827
Requests/sec:  45582.33
Transfer/sec:     34.17MB

CPU 結果和上一個差不多,該壓測結果也有近50%的非正常值,穩定的測試結果,估計得降10%-20%。

為了總結比較,追加將 .NET8 程式部署在IIS,併進行壓力測試:

.NET 部署 IIS 的簡單步驟:.NET Core 8 部署在 IIS 的簡單三步

下麵進行壓測試:

wrk -t128 -c 2000 -d 30s http://192.168.100.102:8011/api/hello

測試結果:qps = 38356【對比:.NET Core 8 Kestrel 對應的 qps = 105462】 

Running 15s test @ http://192.168.100.102:8011/api/hello
  128 threads and 2000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    83.21ms  104.38ms   1.60s    83.56%
    Req/Sec   316.97    235.61     1.95k    70.51%
  579569 requests in 15.11s, 118.46MB read
  Non-2xx or 3xx responses: 8274
Requests/sec:  38356.07
Transfer/sec:      7.84MB

壓測試過程,觀察兩個cpu,虛擬機(150%-190%左右,2核都跑不滿),程式才跑了15%-20%左右,估計還有很大上升空間。

不過測試就這了,主要是整體觀察,有個大體印象,畢竟拋開業務追求更高的數字意義不咋麽大。

總結:

ab 壓測極限:

.NET8【舊電腦:5765(Kestrel),新電腦:18247(Kestrel)】

.NET4【舊電腦:6277(IIS),新電腦:19037(IIS)】

wrk 壓測極限:

.NET8【舊電腦:23303(Kestrel),新電腦:105462(Kestrel)、38356(Kestrel + IIS 反向代理)】

.NET4【舊電腦:14171(IIS),新電腦:47617(IIS 非穩定結果)、36194(IIS 穩定結果)】

從以上的數據對比,可以看出,整體上,.NET Core 使用 Kestrel 時的性能無論是跑在 Window 上,還是跑在 Linux 上,性能都會比.NET 優秀很多。 

如果.NET Core 程式部署在IIS中,經過IIS的反向代理遞減性能後,性能則和 .NET 差不多。

由於系統環境的影響,測試結果和參數,都是時刻在一定的範圍內變化的,因此,測試結果只能當作參考。

附本文的運行程式:Taurus.MVC .NET4 運行程式

 

版權聲明:本文原創發表於 博客園,作者為 路過秋天 本文歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文連接,否則視為侵權。
個人微信公眾號
Donation(掃碼支持作者):支付寶:
Donation(掃碼支持作者):微信:

您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 一、前言 在項目開發過程中,DataGrid是經常使用到的一個數據展示控制項,而通常表格的最後一列是作為操作列存在,比如會有編輯、刪除等功能按鈕。但WPF的原始DataGrid中,預設只支持固定左側列,這跟大家習慣性操作列放最後不符,今天就來介紹一種簡單的方式實現固定右側列。(這裡的實現方式參考的大佬 ...
  • 前言 .NET生態中有許多依賴註入容器。在大多數情況下,微軟提供的內置容器在易用性和性能方面都非常優秀。外加ASP.NET Core預設使用內置容器,使用很方便。 但是筆者在使用中一直有一個頭疼的問題:服務工廠無法提供請求的服務類型相關的信息。這在一般情況下並沒有影響,但是內置容器支持註冊開放泛型服 ...
  • 一:背景 1. 講故事 上個月有個朋友在微信上找到我,說他們的軟體在客戶那邊隔幾天就要崩潰一次,一直都沒有找到原因,讓我幫忙看下怎麼回事,確實工控類的軟體環境複雜難搞,朋友手上有一個崩潰的dump,剛好丟給我來分析一下。 二:WinDbg分析 1. 程式為什麼會崩潰 windbg 有一個厲害之處在於 ...
  • 如果你在自定義的 Main 方法中直接使用 App 類並啟動應用程式,但發現 App.xaml 中定義的資源沒有被正確載入,那麼問題可能在於如何正確配置 App.xaml 與你的 App 類的交互。 確保 App.xaml 文件中的 x:Class 屬性正確指向你的 App 類。這樣,當你創建 Ap ...
  • 一、前言 在自己的項目中,涉及到實時心率曲線的繪製,項目上的曲線繪製,一般很難找到能直接用的第三方庫,而且有些還是定製化的功能,所以還是自己繪製比較方便。很多人一聽到自己畫就害怕,感覺很難,今天就分享一個完整的實時心率數據繪製心率曲線圖的例子;之前的博客也分享給DrawingVisual繪製曲線的方 ...
  • 引言 上一章我們介紹了在xUnit單元測試中用xUnit.DependencyInject來使用依賴註入,上一章我們的Sample.Repository倉儲層有一個批量註入的介面沒有做單元測試,今天用這個示例來演示一下如何用Bogus創建模擬數據 ,和 EFCore 的種子數據生成 Bogus 的優 ...
  • 原因:我之所以想做這個項目,是因為在之前查找關於C#/WPF相關資料時,我發現講解圖像濾鏡的資源非常稀缺。此外,我註意到許多現有的開源庫主要基於CPU進行圖像渲染。這種方式在處理大量圖像時,會導致CPU的渲染負擔過重。因此,我將在下文中介紹如何通過GPU渲染來有效實現圖像的各種濾鏡效果。 生成的效果 ...
  • .NET WebAPI作為一種構建RESTful服務的強大工具,為開發者提供了便捷的方式來定義、處理HTTP請求並返迴響應。在設計API介面時,正確地接收和解析客戶端發送的數據至關重要。.NET WebAPI提供了一系列特性,如[FromRoute]、[FromQuery]和[FromBody],用 ...
一周排行
    -Advertisement-
    Play Games
  • C#.Net的BCL提供了豐富的類型,最基礎的是值類型、引用類型,而他們的共同(隱私)祖先是 System.Object(萬物之源),所以任何類型都可以轉換為Object。 ...
  • 最近有群友咨詢C#如何調用Python?小編嘗試Python.NET過程中遭遇的版本相容性和環境配置難題,小編決定尋找一個更為簡單、穩定且對初學者友好的解決方案。小編搜索一番,除了Python.NET之外,還有其他途徑能夠幫助我們輕鬆地在C#項目調用Python腳本,那就是通過命令行調用,使用 Sy ...
  • .NET中特性+反射 實現數據校驗 在.NET中,我們可以使用特性+反射來實現數據校驗。特性是一種用於為程式中的代碼添加元數據的機制。元數據是與程式中的代碼相關聯的數據,但不直接成為代碼的一部分。通過特性,我們可以為類、方法、屬性等添加額外的信息,這些信息可以在運行時通過反射獲取和使用。 對反射不太 ...
  • Biwen.Settings 是一個簡易的配置項管理模塊,主要的作用就是可以校驗並持久化配置項,比如將自己的配置存儲到資料庫中,JSON文件中等 使用上也是很簡單,只需要在服務中註入配置, 比如我們有一個GithubSetting的配置項,我們只需要定義好對象然後註入到Service中即可: [De ...
  • EDP是一套集組織架構,許可權框架【功能許可權,操作許可權,數據訪問許可權,WebApi許可權】,自動化日誌,動態Interface,WebApi管理等基礎功能於一體的,基於.net的企業應用開發框架。通過友好的編碼方式實現數據行、列許可權的管控。 ...
  • 前言 VB.NET,全名Visual Basic .NET,是Microsoft .NET框架的一部分,是一種面向對象的編程語言。它繼承了Visual Basic的易用性,同時增加了對面向對象編程的支持。VB.NET提供了大量的內置函數,使得開發者可以更容易地處理字元串、數學計算、文件和目錄訪問等任 ...
  • 自定義可移動點二維坐標軸控制項 目錄 路由參數 坐標軸控制項定義 Demo 路由參數 X_YResultCollection為當前X軸對應Y軸值存儲字典 public class ResultCollectionChangedEventArgs(RoutedEvent routedEvent, obje ...
  • 自定義分頁控制項 tip: 該控制項的樣式用的是materialDesign庫,需要下載Nuget包 Code Xaml <UserControl x:Class="TestTool.CustomControls.PagingControl" xmlns="http://schemas.microsof ...
  • 最近群里有個小伙伴把Dapper遷移SqlSugar幾個不能解決的問題進行一個彙總,我正好寫一篇文章來講解一下 一、sql where in傳參問題: SELECT * FROM users where id IN @ids 答: SqlSugar中應該是 var sql="SELECT * FRO ...
  • 安裝nuget包 Wesky.Net.OpenTools 1.0.8或以上版本。支持.net framework 4.6以上版本,以及所有.net core以及以上版本引用。 開發一個簡單的Winform界面,用來測試使用。如需該winform的demo,可以在公眾號【Dotnet Dancer】後 ...