由于很多园友反馈,有的组件不应该缺席、测试复杂度不够、测试还缺乏一定的公平。
因此考虑在下一个版本中,确保在更加公平的前提下进行更高复杂度的测试 。
同时将分为2组测试,纯SQL组件及纯ORM组件, 如果纯SQL组件不足,就只进行纯ORM组件的测试。
待加入测试组件有Dapper、PetaPoco/NPoco、Elinq、FluentData ,有更好的建议,请留言。
--------------------------------------------------------------
“啊!你在用ORM?会不会性能很差啊?”
标题提到的组件“增删改查”都实现了测试代码,所以除了测试外,也可以把此项目作为各个组件的入门参考demo。
源码下载:
git地址: 欢迎园友贡献改进代码。
项目使用的是.Net Framework 4.0可以使用2010或2012打开。
默认测试数据库使用SqlServer
测试前,请先创建数据表Test(使用名为Test的数据库,如果不用这个数据库,请更改数据库连接字符串)
测试前清表:truncatetable Test
默认连接字符串是:Data Source=.;Initial Catalog=Test;Integrated Security=True此程度测试代码使用了接口规范,并没有为了省事耦合在程序里,因此编写修改测试代码非常简单,所以也希望各位园友自己写上一段测试测试。
由于这些组件基本都是第一次使用,所以可能导致部分组件测试代码编写并不合理,敬请指点。 注意:各组件的测试均采用一样的测试思路,也即ORM对ORM,SQL对SQL,循环也是一样的循环。不必拘泥于15和23的区别,而是要区别10和100的区别,也就是在一个数量级别之间比较。 线程我分别写了Task、ThreadPool和Thread的执行方式,根据自己的喜欢选择。先看两张测试图。
分别是ClownFish和EF的测试图,X轴是线程名称,Y轴是耗时。
特别说明: CYQ的数据是使用更新前的组件,在昨晚测试整理的。今天收到秋天园友的反馈,已经在git提交了更新,测试的数据也回归正常。
因此,数据也调整过来。(2013-07-27 13:53)
关于XCode的测试数据,请参看大石头的说明。大石头建议在大数据的访问时使用此组件,并开启缓存。
同时不再接受新的组件更新,除非是在新的测试版本中,以避免针对性的更新。
数据格式:平均值-最高值-最低值
测试顺序:增、改、删100“线程” 查询10次 增删改
| ClownFish | Moon | |
增 | 23-96-2 | 21-76-6 | 8-25-4 |
删 | 16-49-2 | 15-37-5 | 4-18-2 |
改 | 46-116-3 | 23-56-3 | 7-33-3 |
| CYQOrm | EFOrm | MoonOrm | MySoftOrm | NHibernateOrm | PDFOrm | XCodeOrm |
增 | 24-79-5 | 23-71-8 | 10-64-3 | 46-102-24 | 21-47-7 | 12-31-4 | 15-60-9 |
删 | 11-61-4 | 61-137-17 | 10-29-3 | 41-267-15 | 41-103-9 | 20-54-3 | 340-623-173 |
改 | 29-182-18 | 37-113-15 | 5-15-2 | 110-195-52 | 37-128-7 | 17-50-3 | 364-476-246 |
| ClownFish | Moon | |
增 | 9-276-2 | 13-49-2 | 7-44-3 |
删 | 22-125-2 | 7-43-3 | 9-41-3 |
改 | 20-299-2 | 10-123-3 | 8-66-2 |
| CYQOrm | EFOrm | MoonOrm | MySoftOrm | NHibernateOrm | PDFOrm | XCodeOrm |
增 | 79-961-3 | 29-306-9 | 6-52-3 | 50-386-11 | 12-259-4 | 10-48-3 | 14-231-8 |
删 | 29-471-4 | 43-321-11 | 14-95-2 | 78-386-13 | 45-237-7 | 22-90-4 | 362-729-177 |
改 | 30-438-3 | 59-334-12 | 27-215-14 | 106-647-18 | 42-294-4 | 17-128-3 | 410-755-199 |
查询测试,数据行100W
100“线程” 查询返回Top 100 使用没有索引的列RowId排序
| ClownFish | Moon | |
查 | 2-19-1 | 1-9-0 | 1-47-0 |
查询采用的根据组件提供的分页或者Top查询功能。(moon及xcode使用的是分页查询)
使用没有索引的列RowId排序
| CYQOrm | EFOrm | MoonOrm | MySoftOrm | NHibernateOrm | PDFOrm | XCodeOrm |
查 | 1339-2220-281 | 1452-3668-735 | 5230-8032-3241 | 1287-1670-240 | 3372-6264-954 | 2629-3825-836 | 1696-5363-716 |
使用有索引的列Guid排序
| CYQOrm | EFOrm | MoonOrm | MySoftOrm | NHibernateOrm | PDFOrm | XCodeOrm |
查 | 16-32-13 | 5-8-3 | 5967-14644-1639 | 2-5-1 | 7-127-2 | 1-17-0 | 1-9-0 |
经过测试,发现线程越多,越容易出现问题“超时时间已到,但是尚未从池中获取连接。出现这种情况可能是因为所有池连接均在使用,并且达到了最大池大小。”导致访问很不稳定。
一个好的数据访问层应该是可以优雅的接受并处理大并发的访问,而不应该仅仅只盯住表面上的测试数据(除非有数量级上的差距)。整个程序框架怎么才设计出色,更加优雅的面对请求,才是应该花更多心思去考虑的。从上面也可以看到,ORM性能其实并没有一般人想象的那么糟糕。最后看看程序的代码是怎么样的。
项目目录
测试代码接口
ClownFish-SQL测试代码
PDF-SQL测试代码
CYQ-ORM测试代码
EF-ORM测试代码
Moon-ORM测试代码
MySoft-ORM测试代码
NHibernate-ORM测试代码
XCode-ORM测试代码
测试耗时监控
测试完整逻辑代码 ,300多行,慎点。
到底是选择ORM而不写Sql,还是 为了追求性能,而避开ORM,就看自己的情况来取舍了。
选择一个组件的时候,可以考虑这几方面:稳定性、性能、易用性、是否保持更新、是否有较好的文档手册、使用者社区怎么样、是否开源。
上面提供的组件测试代码也可以看到这些组件的代码风格,喜欢语法糖的不妨好好看看,到底更喜欢哪种风格。
综合考虑选择。
QQ交流群:9524888 ,如果想提交测试代码,可以直接发给我,我加上去。
更新修正说明:
由于ClownFish提出测试的时候,使用了匿名对象,因此修改为SQL的直接执行,测试数据如下。
由于1000线程的测试,在500左右,就出现连接超时问题,不能提供测试数据,有兴趣的朋友,自己运行测试。对此造成误解,请谅解。