.NET 6 EFCore WebApi 使用 JMeter 進行吞吐量測試 開發環境 VS2022 .NET 6 測試環境 測試工具 介面壓力測試工具：JMeter 資料庫 MySQL 5.7 資料庫和WebApi服務在同一臺伺服器上，JMeter在本人筆記本上。 測試設置 200個線程併發，每個 ...
.NET 6 EFCore WebApi 使用 JMeter 進行吞吐量測試
開發環境
VS2022
.NET 6
測試環境
測試工具
介面壓力測試工具：JMeter
資料庫
MySQL 5.7
資料庫和WebApi服務在同一臺伺服器上，JMeter在本人筆記本上。
測試設置
200個線程併發，每個線程迴圈50次，共10000次請求。
介面代碼
模糊查詢、排序、分頁查詢第10頁200條數據，參數化查詢條件。
EFCore (第一輪請求)，測試結果
服務程式部署到測試伺服器上測試，連接MySql資料庫。
吞吐量
只有200多
每個請求響應時間
最長5秒多
EFCore (第一輪請求結束後，20秒內進行第二輪請求)，測試結果
服務程式部署到測試伺服器上測試，連接MySql資料庫。
經過第一輪10000個請求的充分預熱，取第二輪10000個請求的測試結果。
吞吐量
1200多
每個請求響應時間
不到50毫秒
線程占用
最大達到143個線程
EFCore (第一輪請求結束後，20秒後進行第二輪請求)，測試結果
吞吐量
1200
每次請求響應時間
100毫秒
線程占用
只有50多個線程
使用FactoryStartNew. StartNewThread
查詢代碼
FactoryStartNew. StartNewThread代碼
使用FactoryStartNew. StartNewThread (第一輪請求)，測試結果
服務程式部署到測試伺服器上測試，連接MySql資料庫。
吞吐量
不到200
每個請求響應時間
最長33秒
使用FactoryStartNew. StartNewThread (第一輪請求結束後，20秒內進行第二輪請求)，測試結果
吞吐量
1000多
每個請求響應時間
200毫秒以內
線程占用
高達260多個線程
使用FactoryStartNew. StartNewThread (第一輪併發請求結束後，20秒後進行第二輪請求)，測試結果
吞吐量
只有200多
每個請求響應時間
最長達到了30秒
在等待創建線程，.NET預設線程池，1秒才增加一個線程
線程占用
高達230多個線程
對比SqlSugar
同樣的資料庫，同樣的數據，同樣的查詢，同樣的JMeter測試設置，同樣取第二輪測試結果。
吞吐量
395
每個請求響應時間
500毫秒
對比FreeSql
同樣的資料庫，同樣的數據，同樣的查詢，同樣的JMeter測試設置，同樣取第二輪測試結果。
吞吐量
408
每個請求響應時間
不到500毫秒
對比Dapper.LiteSql
吞吐量
480多
每個請求響應時間
400多毫秒
結論
1. EFCore優秀，吞吐量和響應時間都非常優秀。
2. 使用FactoryStartNew. StartNewThread，能用，但有問題。
3. 如果覺得自己的ORM沒問題，那就沒有問題了，誰沒事閑的做這種測試，慢一點不會死人，用戶多了併發多了就加機器，作者和用戶永遠也不會知道，明明可以達到1000的吞吐量，卻一直用的280吞吐量的ORM。
4. 比EFCore慢不丟人。
5. 不要說代碼怎麼寫的，我要看測試結果。
測試工程地址
https://gitee.com/s0611163/Net6WebApiPerformanceTest
