一次Dapper高並發測試報告記錄. 結果....，dapper測試報告

一次Dapper高並發測試報告記錄. 結果....，dapper測試報告

一直聽說dapper的數據處理能力很強. 我也一直很喜歡. 不過最近的一次壓力測試卻出乎我的意料....


好久沒寫東西,感覺自己都不知道怎麼表達自己的意思了.   另外 這次的測試也是自己才開始的 . 也不知道測試思路和方式是否正確.  各位有什麼就來吐槽吐槽吧.

測試代碼下載

http://pan.baidu.com/s/1dDzuEi9 

2種操作db方式.

1 純mysql操作db

2 dapper方式操作db

 

測試方式1
一個用戶 運行代碼n次數,測試代碼執行消耗.在這個模式比較下. dapper 的 CURD操作和純粹的手寫sql效率差別基本不大. 下圖是幾個操作的對比.

 








可以看到在這個情況下dapper和手寫代碼性能差異不大. 甚至有優勢.  但是可以發現dapper其實在cpu運算消耗,gc回收,其實消耗了更多的資源.
當然我這裡測試的次數不高. 還可以用更高的次數去壓看看. 我也嘗試過運行1w次 10w次的效率. 都是差異不大.

 

測試方式2

使用 loadrunner 壓力測試工具 ,多用戶多並發.

 dapper 模擬300用戶請求, 隨機翻頁
 原生態mysql模擬300用戶請求, 隨機翻頁





對比可以看見

對比項 (300並發) dapper  原生態mysql 響應時間 單位s 4.3 1.4 事務通過總數/s 約108 310-350                  

 

 

 

 

 

 

 

2個關鍵的參數在用戶並發的情況下, dapper 的響應大大減小. 在達到500並發的情況下. 這個數值還會遞減至11s. 並且事物通過數也下降至50個/s內. 明顯不如手寫方式的.

 

 

 

 

 

通過測試我的問題是:

1. 在高並發下dapper的性能真的下降很多嗎, 還是我的測試方法有問題?

2. 如果dapper在高並發下真的下降很多, 改如何去改進他的這一問題?

 

 

測試代碼下載

http://pan.baidu.com/s/1dDzuEi9