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
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...