前言：
上次釋出了：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 執行程式
