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
  • 不廢話,直接代碼 private Stack<Action> actionStack = new Stack<Action>(); private void SetCellValues() { var worksheet = Globals.ThisAddIn.Application.ActiveS ...
  • OpenAPI 規範是用於描述 HTTP API 的標準。該標準允許開發人員定義 API 的形狀,這些 API 可以插入到客戶端生成器、伺服器生成器、測試工具、文檔等中。儘管該標準具有普遍性和普遍性,但 ASP.NET Core 在框架內預設不提供對 OpenAPI 的支持。 當前 ASP.NET ...
  • @DateTimeFormat 和 @JsonFormat 是 Spring 和 Jackson 中用於處理日期時間格式的註解,它們有不同的作用: @DateTimeFormat @DateTimeFormat 是 Spring 框架提供的註解,用於指定字元串如何轉換為日期時間類型,以及如何格式化日 ...
  • 一、背景說明 1.1 效果演示 用python開發的爬蟲採集軟體,可自動抓取抖音評論數據,並且含二級評論! 為什麼有了源碼還開發界面軟體呢?方便不懂編程代碼的小白用戶使用,無需安裝python、無需懂代碼,雙擊打開即用! 軟體界面截圖: 爬取結果截圖: 以上。 1.2 演示視頻 軟體運行演示視頻:見 ...
  • SpringBoot筆記 SpringBoot文檔 官網: https://spring.io/projects/spring-boot 學習文檔: https://docs.spring.io/spring-boot/docs/current/reference/html/ 線上API: http ...
  • 作為後端工程師,多數情況都是給別人提供介面,寫的好不好使你得重視起來。 最近我手頭一些活,需要和外部公司對接,我們需要提供一個介面文檔,這樣可以節省雙方時間、也可以防止後續扯皮。這是就要考驗我的介面是否規範化。 1. 介面名稱清晰、明確 顧名思義,介面是做什麼的,是否準確、清晰?讓使用這一眼就能知道 ...
  • 本文介紹基於Python語言,遍歷文件夾並從中找到文件名稱符合我們需求的多個.txt格式文本文件,並從上述每一個文本文件中,找到我們需要的指定數據,最後得到所有文本文件中我們需要的數據的合集的方法~ ...
  • Java JUC&多線程 基礎完整版 目錄Java JUC&多線程 基礎完整版1、 多線程的第一種啟動方式之繼承Thread類2、多線程的第二種啟動方式之實現Runnable介面3、多線程的第三種實現方式之實現Callable介面4、多線的常用成員方法5、線程的優先順序6、守護線程7、線程的讓出8、線 ...
  • 實時識別關鍵詞是一種能夠將搜索結果提升至新的高度的API介面。它可以幫助我們更有效地分析文本,並提取出關鍵詞,以便進行進一步的處理和分析。 該介面是挖數據平臺提供的,有三種模式:精確模式、全模式和搜索引擎模式。不同的模式在分詞的方式上有所不同,適用於不同的場景。 首先是精確模式。這種模式會儘量將句子 ...
  • 1 為啥要折騰搭建一個專屬圖床? 技術大佬寫博客都用 md 格式,要在多平臺發佈,圖片就得有外鏈 後續如博客遷移,國內博客網站如掘金,簡書,語雀等都做了防盜鏈,圖片無法遷移 2 為啥選擇CloudFlare R2 跳轉:https://dash.cloudflare.com/ 有白嫖額度 免費 CD ...