一次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用户请求, 随机翻页





对比可以看见

2个关键的参数在用户并发的情况下, dapper 的响应大大减小. 在达到500并发的情况下. 这个数值还会递减至11s. 并且事物通过数也下降至50个/s内. 明显不如手写方式的.

通过测试我的问题是:

1. 在高并发下dapper的性能真的下降很多吗, 还是我的测试方法有问题?

2. 如果dapper在高并发下真的下降很多, 改如何去改进他的这一问题?

测试代码下载

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

6楼茗::流

不错

5楼笋干

再拿Update/Insert什么的来说，明显不对等嘛，你手敲的参数 和dapper映射这里的损耗也不对等啊，换成mysql换成反射还差不多。，dapper官方也说了你手敲的原生datareader 效率是第一高的。，dapper也是基于datareader做的嘛，所以你这么测试就相当于测试一个原生方法 和一个包装的原生方法的差异，这个很明显的呀。，，最最重要的是，我觉得dapper的高效是映射到T的高效，不是查询，sql执行高效。orm是为了解决频繁手敲代码的工作量，牺牲了一点性能。 所以我才说这个比较没啥意义。

Re: colvinliu

@笋干， public void TestExecuteAsync() { using (var connection = Program.GetOpenConnection()) { var query = connection.ExecuteAsync(quot;declare @foo table(id int not null); insert @foo values(@id);quot;, new { id = 1

4楼muki

mark.

3楼酷小孩

坐等大牛们来辩。。。

2楼最爱晴天

本人很喜欢dapper~~~

1楼笋干

感觉比较完全没意义啊，代码里dapper做object转化了，原生sql直接datareader/datatable 完全不同的操作啊。

Re: colvinliu

@笋干，为什么没有意义?? dapper的优势是说性能出色. 通过测试可以看出在单用户模式下是这样的. 不过在高并发情况下 , 性能差很多. 甚至比不上我们自己的反射构造sql操作db的情况.... 这也是我拉出来讨论的原因.