测试 ClownFish、CYQ、Entity Framework、Moon、MySoft、NHibernate、PDF、XCode数据访问组件性能

简介:
下期预告:

由于很多园友反馈,有的组件不应该缺席、测试复杂度不够、测试还缺乏一定的公平。

因此考虑在下一个版本中,确保在更加公平的前提下进行更高复杂度的测试 。

同时将分为2组测试,纯SQL组件及纯ORM组件, 如果纯SQL组件不足,就只进行纯ORM组件的测试。

待加入测试组件有Dapper、PetaPoco/NPoco、Elinq、FluentData ,有更好的建议,请留言。

-------------------------------------------------------------- 

“啊!你在用ORM?会不会性能很差啊?”

用数字来说话,打破模糊的、传言的印象。

标题提到的组件“增删改查”都实现了测试代码,所以除了测试外,也可以把此项目作为各个组件的入门参考demo。 

源码下载:https://github.com/alifellod/DbAccessLibTest/archive/master.zip

git地址:https://github.com/alifellod/DbAccessLibTest  欢迎园友贡献改进代码。

项目使用的是.Net Framework 4.0可以使用2010或2012打开。

 

默认测试数据库使用SqlServer 

测试前,请先创建数据表Test(使用名为Test的数据库,如果不用这个数据库,请更改数据库连接字符串)

复制代码
CREATE  TABLE  [ dbo ]. [ Test ]
(
     [ RowId ]  [ int ]  IDENTITY( 1, 1NOT  NULL,
     [ Guid ]  [ varchar ]( 50primary  key  NOT  NULL,
     [ Content ]  [ nvarchar ]( 500NULL,
     [ CreateDate ]  [ datetime ]  NULL  default  getdate(),
     [ EditDate ]  [ datetime ]  NULL
)
复制代码

 

测试前清表:truncatetable Test
默认连接字符串是:Data Source=.;Initial Catalog=Test;Integrated Security=True

此程度测试代码使用了接口规范,并没有为了省事耦合在程序里,因此编写修改测试代码非常简单,所以也希望各位园友自己写上一段测试测试。
由于这些组件基本都是第一次使用,所以可能导致部分组件测试代码编写并不合理,敬请指点。
注意:各组件的测试均采用一样的测试思路,也即ORM对ORM,SQL对SQL,循环也是一样的循环。
不必拘泥于15和23的区别,而是要区别10和100的区别,也就是在一个数量级别之间比较。
线程我分别写了Task、ThreadPool和Thread的执行方式,根据自己的喜欢选择。

Task可以很出色的取消创建的线程,ThreadPool测试会较为稳定,Thread很容易导致SQL连接池爆破。
测试之前,可先预热一下——各个组件进行一定数量查询。

先看两张测试图。 

分别是ClownFish和EF的测试图,X轴是线程名称,Y轴是耗时。 

 

 

特别说明: CYQ的数据是使用更新前的组件,在昨晚测试整理的。今天收到秋天园友的反馈,已经在git提交了更新,测试的数据也回归正常。

因此,数据也调整过来。(2013-07-27 13:53) 

关于XCode的测试数据,请参看大石头的说明。大石头建议在大数据的访问时使用此组件,并开启缓存。 

同时不再接受新的组件更新,除非是在新的测试版本中,以避免针对性的更新。 

数据格式:平均值-最高值-最低值
测试顺序:增、改、删
100“线程” 查询10次 增删改
 

 

ClownFish

Moon

PDF

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

PDF

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

PDF

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性能其实并没有一般人想象的那么糟糕。

最后看看程序的代码是怎么样的。

项目目录

测试代码接口

  View Code

ClownFish-SQL测试代码

  View Code
Moon-SQL测试代码
  View Code

PDF-SQL测试代码

  View Code

CYQ-ORM测试代码

  View Code

EF-ORM测试代码

  View Code

Moon-ORM测试代码

  View Code

MySoft-ORM测试代码

  View Code

NHibernate-ORM测试代码

  View Code
PDF-ORM 测试代码
View Code

XCode-ORM测试代码

  View Code

测试耗时监控

  View Code

测试完整逻辑代码 ,300多行,慎点。

  View Code

 
到底是选择ORM而不写Sql,还是 为了追求性能,而避开ORM,就看自己的情况来取舍了。 

选择一个组件的时候,可以考虑这几方面:稳定性、性能、易用性、是否保持更新、是否有较好的文档手册、使用者社区怎么样、是否开源

上面提供的组件测试代码也可以看到这些组件的代码风格,喜欢语法糖的不妨好好看看,到底更喜欢哪种风格。

综合考虑选择。 

 

各组件地址
ClownFish: http://www.cnblogs.com/fish-li/ 【不开源】仅此一个是非ORM的。
CYQ: http://www.cnblogs.com/cyq1162/ 【逐版本开源】
EF:  https://entityframework.codeplex.com/ 【开源】
Moon: http://www.cnblogs.com/humble/ 【不开源】
MySoft: http://www.cnblogs.com/maoyong/archive/2010/03/01/1675730.html 【逐版本开源】
NHibernate: http://nhforge.org/ 【开源】
PDF: http://www.cnblogs.com/bluedoctor/【开源】
XCode: http://xcode.codeplex.com/ 【开源】
希望更多的园友分享或开源自己所能知道的心爱的数据访问组件。

QQ交流群:9524888 ,如果想提交测试代码,可以直接发给我,我加上去。

更新修正说明:

由于ClownFish提出测试的时候,使用了匿名对象,因此修改为SQL的直接执行,测试数据如下。

由于1000线程的测试,在500左右,就出现连接超时问题,不能提供测试数据,有兴趣的朋友,自己运行测试。对此造成误解,请谅解。

 

100-10 insert
37-375-5
215-611-29
223-562-40
12-181-3
7-21-4
10-138-3
8-71-4
11-187-4
25-227-3
107-829-3
265-679-15
226-609-19

100-10-delete
10-90-2
24-115-3
33-282-2
37-174-3
111-537-2
23-203-2
8-54-3

100-10-update
11-174-3
16-190-4
21-69-2
21-58-4
75-1155-3

 


本文转自火地晋博客园博客,原文链接:http://www.cnblogs.com/yelaiju/p/3209506.html,如需转载请自行联系原作者

目录
相关文章
|
21天前
|
网络协议 安全 测试技术
性能工具之emqtt-bench BenchMark 测试示例
【4月更文挑战第19天】在前面两篇文章中介绍了emqtt-bench工具和MQTT的入门压测,本文示例 emqtt_bench 对 MQTT Broker 做 Beachmark 测试,让大家对 MQTT消息中间 BenchMark 测试有个整体了解,方便平常在压测工作查阅。
115 7
性能工具之emqtt-bench BenchMark 测试示例
|
21天前
|
设计模式 测试技术 持续交付
深入白盒测试:提升软件质量与性能的关键策略
【4月更文挑战第20天】 在软件开发的复杂世界中,确保产品的质量和性能始终是至关重要的任务。白盒测试,作为软件测试领域的重要分支,提供了对程序内部结构和逻辑的深入分析手段。本文将探讨如何通过有效的白盒测试策略来优化软件性能,减少缺陷,并最终提高用户满意度。通过剖析代码检查、单元测试、集成测试等白盒测试技术,我们将了解这些方法如何揭示潜在的问题点,并为改进提供方向。
|
1月前
|
安全 算法 测试技术
深入白盒测试:提升软件质量与性能的关键策略
【4月更文挑战第7天】 在软件开发生命周期中,确保代码的质量和性能至关重要。白盒测试作为一种重要的测试方法,允许测试者通过检查程序内部结构和逻辑来识别缺陷和问题。本文旨在探讨白盒测试的核心原则、技术及其对提升软件产品可靠性的影响。我们将重点分析如何利用白盒测试进行有效的单元测试、集成测试以及系统测试,并讨论现代软件测试工具如何帮助实现自动化测试流程,从而优化开发周期并降低错误率。
|
1天前
|
算法 测试技术 Linux
LabVIEW NI CompactRIO控制器:性能和吞吐量基准测试
LabVIEW NI CompactRIO控制器:性能和吞吐量基准测试
|
1天前
|
Linux 测试技术 Windows
LabVIEW对NI Linux RT应用程序性能进行基准测试
LabVIEW对NI Linux RT应用程序性能进行基准测试
|
4天前
|
JSON 测试技术 数据格式
Elasticsearch 8.X 如何生成 TB 级的测试数据 ?
Elasticsearch 8.X 如何生成 TB 级的测试数据 ?
13 0
|
12天前
|
分布式计算 Hadoop 测试技术
|
12天前
|
分布式计算 Hadoop 测试技术
|
12天前
|
分布式计算 Hadoop 测试技术
Hadoop节点网络性能的带宽测试
【4月更文挑战第23天】
24 1
|
13天前
|
人工智能 测试技术
测试数据不再难,人工智能批量生成给你用!
本文介绍了如何利用ChatGPT生成测试数据。测试数据是验证功能和触发异常场景的关键,设计时需全面考虑等价类、边界值和正交法。实践中,先明确数据类型、格式和需求,然后向ChatGPT提供相关信息。例如,对于只能输入中国手机号的输入框,初始提示可能只包含正常手机号,但应进一步补充异常场景,如非数字、长度错误、非中国号码、特殊字符、空输入等。此外,可通过指定yaml格式来满足代码使用需求。总结来说,生成测试数据需清晰定义需求,拆分任务,并系统测试各种变化。
21 2

热门文章

最新文章