一次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