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

转载于:https://www.cnblogs.com/colvinliu/p/4533794.html