如何优化ORM性能测试Benchmark,实现效果的最佳实践?
摘要:ORM性能测试Benchmark(最终版) 本测试聚焦 ORM 在查询过程中,对查询表达式解析、数据映射、流程处理的性能差异。 由于 SQL 的实际执行由数据库引擎负责,ORM 无法改变数据库层面的执行逻辑;不同 ORM 的差异主要体现在
ORM性能测试Benchmark(最终版)
本测试聚焦 ORM 在查询过程中,对查询表达式解析、数据映射、流程处理的性能差异。
由于 SQL 的实际执行由数据库引擎负责,ORM 无法改变数据库层面的执行逻辑;不同 ORM 的差异主要体现在 SQL 拼接、表达式解析和数据映射等实现细节(例如插入操作可通过生成 SQL 或使用 BulkCopy 实现)。
因此,本测试不对实现方式完全不同的操作(如 BulkCopy)进行比较,而是重点衡量表达式解析与数据映射两方面的运行效率与内存占用。
测试声明
本测试不代表任何立场和原作者也没任何关系,仅是在研究、学习、优化、测试,对内部项目myTest整理过程中形成的测试,有其它测式可下载源码自行添加实现。
测试环境
项目
说明
测试框架
BenchmarkDotNet
测试数据库
SQLite(单机性能优,波动较小)
.NET 版本
.NET 6.0+
测试硬件
Intel Core i5-8265U CPU 1.60GHz
测试的ORM
下面列出了近年收集到的ORM,除Dapper外,未涉及到表达式解析的ORM没有加入此测试
<PackageReference Include="Chloe.SQLite" Version="5.55.0" />
<PackageReference Include="Dapper" Version="2.1.66" />
<PackageReference Include="FreeSql.Provider.Sqlite" Version="3.5.305" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="8.0.0-preview.6.23329.4" />
<PackageReference Include="SqlSugarCore" Version="5.1.4.212-preview02" />
<PackageReference Include="linq2db" Version="6.2.0" />
<Reference Include="Fast.Framework">
具体测试项目如下
对表达式解析进行测试 testQueryCondition
对查询返回结果进行数据映射测试 testQueryResult
自定义数据映射测试 testQueryAnonymousResult
循环读取指定数据测试 testQueryLoop
测试代码明细
对表达式解析进行测试 testQueryCondition
指定了查询条件和返回结果筛选
这里可以反映表达式解析生成SQL效率,ORM技术核心最困难的部份,非常考验代码组织和逻辑
query.Where(b => b.F_String == "111" && b.F_Decimal > 0 && b.F_Bool == true && b.F_String.StartsWith("abc")).Select(b => new { b.F_Float, b.F_Bool, b.F_Double, b.F_Byte, b.F_String, b.F_Decimal, b.F_Int64 }).ToSqlString();
对查询返回结果进行数据映射测试 testQueryResult
返回指定的数量的数据进行数据映射,以测试映射效率和内存使用情况
query.Take(100).ToList();
自定义数据映射测试 testQueryAnonymousResult
指定数据映射的结构,以测试解析和映射效率、内存使用情况
这里使用了匿名对象,是一个比较特殊的处理
query.Take(100).Select(b => new
{
b.Id,
b.F_Float,
b.F_Bool,
b.F_DateTime,
b.F_Decimal,
b.F_Double,
b.F_Int64
}).ToList();
循环读取指定数据测试 testQueryLoop
循环多次查询,以测试查询和映射效率
这里验证数据连接效率和查询效率,虽然每次查询的数据量很小,但循环多次会放大差异,能更明显的看出差别
for (var i = 0; i < 20; i++)
{
var item = query.Where(b => b.Id == i).ToList();
}
Benchmark测试代码样例
[MemoryDiagnoser]
public class ConditionTest : TestBase
{
[Benchmark]
public void TestCondition()
{
Invoke(b => b.testQueryCondition());
}
}
以下是具体测试结果,仅供参考
表格字段说明:
Mean: 所有测量值的算术平均值 ns纳秒 μs微秒 ms毫秒。
Error: 99.9% 置信区间的一半。
StdDev: 所有测量值的标准差。
Gen0: 第 0 代 GC 每 1000 次操作收集一次。
Gen1: 第 1 代 GC 每 1000 次操作收集一次。
Gen2: 第 2 代 GC 每 1000 次操作收集一次。
Allocated: 每次操作分配的内存(仅托管内存,包含所有内容,1KB = 1024B)。
TestCondition
Dapper由于没有表达式解析,空跑,最低和最高不管是效率和内存占用差了一数量级
提示:拼接SQL会导致注入风险,除了语法字符外还有字符编码问题
Method
ProvideType
Mean
Error
StdDev
Gen0
Gen1
Allocated
TestCondition
ChloeTest
90.75 μs
1.020 μs
0.954 μs
5.3711
-
16.68 KB
TestCondition
EfSqlliteTest
217.38 μs
2.950 μs
2.615 μs
19.5313
-
61.19 KB
TestCondition
FastFrameworkTest
94.90 μs
0.807 μs
0.630 μs
6.7139
-
20.71 KB
TestCondition
FreeSqlTest
779.56 μs
12.514 μs
11.706 μs
9.7656
3.9063
62.56 KB
TestCondition
LinqToDbTest
103.50 μs
2.002 μs
2.056 μs
6.1035
-
18.79 KB
TestCondition
MyTest
43.00 μs
0.505 μs
0.395 μs
4.8218
-
14.95 KB
TestCondition
SqlSugarTest
366.82 μs
7.205 μs
6.016 μs
33.6914
-
103.83 KB
TestResult
强类型直接转换,最低和最高差别两倍,EF效率比大部份好
Method
ProvideType
Mean
Error
StdDev
Gen0
Gen1
Allocated
TestResult
ChloeTest
582.8 μs
10.02 μs
8.37 μs
22.4609
-
70.68 KB
TestResult
DapperTest
500.8 μs
3.14 μs
2.94 μs
16.6016
-
52.68 KB
TestResult
EfSqlliteTest
1,127.4 μs
15.77 μs
14.75 μs
64.4531
-
202.9 KB
TestResult
FastFrameworkTest
11,561.9 μs
119.70 μs
93.46 μs
46.8750
-
153.21 KB
TestResult
FreeSqlTest
1,300.0 μs
24.25 μs
22.68 μs
31.2500
11.7188
96.32 KB
TestResult
LinqToDbTest
1,273.8 μs
20.71 μs
18.36 μs
17.5781
-
54.77 KB
TestResult
MyTest
600.5 μs
11.94 μs
11.16 μs
15.6250
-
48.34 KB
TestResult
SqlSugarTest
1,408.5 μs
27.42 μs
38.44 μs
46.8750
-
147.57 KB
TestAnonymousResult
Dapper由于没有结果筛选,同TestResult(SqlSugar内存溢出?)
Method
ProvideType
Mean
Error
StdDev
Gen0
Gen1
Allocated
TestAnonymousResult
ChloeTest
552.7 μs
5.48 μs
4.86 μs
20.5078
-
65.54 KB
TestAnonymousResult
DapperTest
484.2 μs
4.71 μs
4.18 μs
17.5781
-
55.8 KB
TestAnonymousResult
EfSqlliteTest
692.2 μs
11.48 μs
10.74 μs
33.2031
-
103.18 KB
TestAnonymousResult
FastFrameworkTest
7,838.4 μs
67.26 μs
52.51 μs
31.2500
-
122.4 KB
TestAnonymousResult
FreeSqlTest
1,940.9 μs
20.24 μs
18.93 μs
70.3125
11.7188
225.84 KB
TestAnonymousResult
LinqToDbTest
1,241.1 μs
18.58 μs
14.51 μs
15.6250
-
53.21 KB
TestAnonymousResult
MyTest
473.4 μs
4.67 μs
4.14 μs
12.6953
-
39.89 KB
TestAnonymousResult
SqlSugarTest
8,667.7 μs
133.08 μs
111.13 μs
1046.8750
-
3210.65 KB
TestQueryLoop
循环多次查询调用,由于调用sqlite驱动不同,时间差别较大,但从内存使用上能看出差别
Method
ProvideType
Mean
Error
StdDev
Gen0
Gen1
Allocated
TestQueryLoop
ChloeTest
2.535 ms
0.0427 ms
0.0379 ms
74.2188
-
231.78 KB
TestQueryLoop
DapperTest
1.433 ms
0.0274 ms
0.0243 ms
17.5781
-
54.7 KB
TestQueryLoop
EfSqlliteTest
5.410 ms
0.0697 ms
0.0618 ms
375.0000
-
1156.31 KB
TestQueryLoop
FastFrameworkTest
230.424 ms
4.5239 ms
4.0103 ms
666.6667
-
2332.27 KB
TestQueryLoop
FreeSqlTest
16.176 ms
0.3208 ms
0.6257 ms
93.7500
31.2500
664.93 KB
TestQueryLoop
LinqToDbTest
16.881 ms
0.2541 ms
0.2252 ms
125.0000
-
406.34 KB
TestQueryLoop
MyTest
2.058 ms
0.0405 ms
0.0379 ms
46.8750
-
148.13 KB
TestQueryLoop
SqlSugarTest
4.210 ms
0.0739 ms
0.0655 ms
210.9375
-
651.17 KB
引入不同数据库实现的方式
本次测试使用的sqlite数据库,各种引入的方式也不相司,大致分为三类:
引用相关数据库的项目扩展包(ORM主体+扩展+数据库驱动)
直接包含所有支持的数据库驱动(ORM主体+数据库驱动*N)
按需自动或手动配置引入的数据库驱动(ORM主体+按需数据库驱动)
对于第一种,多数项目都采用这种方式,缺点是需要引入多个包,增加了依赖关系,并且强绑定了数据库驱动
对于第二种,虽然可以支持多种数据库,但会增加项目的体积,并且可能引入不必要的依赖,也强绑定了数据库驱动
对于第三种,封装度最高,虽然可以按需引入数据库驱动,减少了项目的体积和依赖复杂度,但由于没有强依赖,部份实现可能由于驱动不一致而实现复杂,如 BulkCopy
以LinqToDb为例,直接引入LinqToDb包,手动配置连接串 new DataOptions().UseConnectionString(ProviderName.SQLite, ITest.sqlLiteDb) 它就能自别识别当前项目引入的sqlite驱动,并且对特殊方法也进行了封装(BulkCopy),不管是哪种数据库,引入驱动后所有方法行为一至,无其它依赖。
各种测试项目的引入方式如下表所示:
ProvideType
引入方式
ChloeTest
扩展包&手动配置
DapperTest
扩展包
EfSqlliteTest
扩展包
FastFrameworkTest
手动配置
FreeSqlTest
扩展包
MyTest
手动或自动配置
SqlSugarTest
全包含
LinqToDbTest
自动配置
如何使用此测试
使用Release发布此项目
运行dbTest.exe
输入序号选择需要运行测试的方法,示例如下
---------------------[ Program ]---------------------
[1] testQueryResult [2] testQueryAnonymousResult
[3] testQueryCondition [4] testQueryLoop
[5] testMethod
---------------------[ invokeAll ]---------------------
[6] invokeAll
invoke method:
输入序号后回车,等待测试完成,测试结果会输出到控制台,并在运行目录生成BenchmarkDotNet.Artifacts文件夹,里面有详细的测试结果和分析报告
运行效果截图
测试项目代码
https://gitee.com/hubro/dbTest.git
参考
使用 BenchmarkDotNet 对 .NET 代码进行性能基准测试
https://cloud.tencent.com/developer/article/2483382
mysql注入-字符编码技巧
https://developer.aliyun.com/article/1658273
