标签：
一直听说dapper的数据处理能力很强. 我也一直很喜欢. 不过最近的一次压力测试却出乎我的意料....
写在最后. 好久没写东西,感觉自己都不知道怎么表达自己的意思了. 另外 这次的测试也是自己才开始的 . 也不知道测试思路和方式是否正确. 各位有什么就来吐槽吐槽吧.
测试代码下载
http://pan.baidu.com/s/1dDAjZnN
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/1dDAjZnN
标签：
原文地址：http://www.cnblogs.com/colvinliu/p/4533794.html
