因为不少园友反馈,有的组件不该该缺席、测试复杂度不够、测试还缺少必定的公平。html
所以考虑在下一个版本中,确保在更加公平的前提下进行更高复杂度的测试 。
git
同时将分为2组测试,纯SQL组件及纯ORM组件, 若是纯SQL组件不足,就只进行纯ORM组件的测试。
github
待加入测试组件有Dapper、PetaPoco/NPoco、Elinq、FluentData ,有更好的建议,请留言。
sql
--------------------------------------------------------------
数据库
“啊!你在用ORM?会不会性能不好啊?”xcode
标题提到的组件“增删改查”都实现了测试代码,因此除了测试外,也能够把此项目做为各个组件的入门参考demo。
缓存
源码下载:https://github.com/alifellod/DbAccessLibTest/archive/master.zipsession
git地址:https://github.com/alifellod/DbAccessLibTest 欢迎园友贡献改进代码。
并发
项目使用的是.Net Framework 4.0可使用2010或2012打开。 app
默认测试数据库使用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 |
1000“线程” 查询10次增删改
|
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左右,就出现链接超时问题,不能提供测试数据,有兴趣的朋友,本身运行测试。对此形成误解,请谅解。