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