Mego(1) - NET中主流ORM框架性能对比

从刚刚开始接触ORM到现在已有超过八年时间,用过了不少ORM框架也了解了不少ORM框架,看过N种关于ORM框架的相关资料与评论,各种言论让人很难选择。在ORM的众多问题中最突出的问题是关于性能方面的问题,因此我在看了国外的一遍文章(Dapper vs Entity Framework vs ADO.NET Performance Benchmarking)后受到启发,在这个文章的基础上扩展了测试用例分享给大家。

  • 模型准备
  • 数据初始化
  • 测试用例说明
  • 测试结果
  • 结果分析

模型准备

用于测试是模型是基于一个订单系统,如下图所示,主要有客户、产品、仓库、订单及订单明细。其中数据表之前的关系从图中可以看出,此外产品、订单明细是自增列,仓库是两个主键构成的复合主键表。虽然只有5张表,但是已经包含了数据表的常用情况。

数据初始化

我们使用以上代码创建数据库,初始化数据表结构,生成测试数据,生成数据量如下表所示。

 1 static void InitialDatabase()
 2 {
 3     using (var ef = new Models.EFContext())
 4     {
 5         if (!ef.Database.Exists())
 6         {
 7             ef.Database.Create();
 8
 9             using (var db = new Models.MegoContext())
10             {
11                 db.InitialTable();
12             }
13         }
14     }
15     using (var db = new Models.MegoContext())
16     {
17         db.InitialData();
18     }
19 }
表名 说明 行数
Customers 客户表 10000
Products 产品表 9000
Warehouses 仓库表 30176
Orders 订单表 100000
OrderDetails 订单明细 600271

这些数据量已经快接近一个小型系统的数据量了,如果需要到本地执行,请将App.config文件中的连接字符串改成自己的数据库名直接运行即可。

测试用例说明

目前参与测试的框架如下:

本测试中的例子不仅仅限定于目前指定的这几种框架,这里定义了一个接口,如果想加入更多测试框架可以参考代码自行加入。

 1     /// <summary>
 2     /// 性能测试项目
 3     /// </summary>
 4     public interface IPerformanceTest
 5     {
 6         /// <summary>
 7         /// 框架名称。
 8         /// </summary>
 9         string Framework { get; }
10         /// <summary>
11         /// 随机获取一个客户
12         /// </summary>
13         /// <param name="id"></param>
14         /// <returns></returns>
15         long GetCustomerById(int id);
16         /// <summary>
17         /// 随机获取一个订单的所有明细
18         /// </summary>
19         /// <param name="orderId"></param>
20         /// <returns></returns>
21         long GetDetailsByOrder(int orderId);
22         /// <summary>
23         /// 随机获取一个订单及所有明细
24         /// </summary>
25         /// <param name="orderId"></param>
26         /// <returns></returns>
27         long GetOrderAndDetails(int orderId);
28         /// <summary>
29         /// 插入离散的N个客户。
30         /// </summary>
31         /// <returns></returns>
32         long InsertDiscreteCustomers(Customer[] customers);
33         /// <summary>
34         /// 插入离散的N个产品,自增主键。
35         /// </summary>
36         /// <returns></returns>
37         long InsertDiscreteProducts(Product[] products);
38         /// <summary>
39         /// 更新离散的N个客户。
40         /// </summary>
41         /// <returns></returns>
42         long UpdateDiscreteCustomers(Customer[] customers);
43         /// <summary>
44         /// 删除离散的N个明细。
45         /// </summary>
46         /// <returns></returns>
47         long DeleteDiscreteDetails(OrderDetail[] details);
48         /// <summary>
49         /// 删除离散的N个仓库,多主键。
50         /// </summary>
51         /// <returns></returns>
52         long DeleteDiscreteWarehouses(Warehouse[] warehouses);
53     }

我们主要有如下表几项测试(输出标题用于在结果中显示):

方法名 每次的测试量 输出标题 测试说明
GetCustomerById 随机查询100次。 SELECT1 随机用主键获取指定客户数据。
GetDetailsByOrder 随机查询100次。 SELECT2 随机用订单主键获取相关的订单明细数据。
GetOrderAndDetails 随机查询100次。 SELECT3 随机用订单主键获取当前订单及所有订单明细数据。
InsertDiscreteCustomers 插入500条数据。 INSERT1 插入指定数量的客户。
InsertDiscreteProducts 插入500条数据。 INSERT2 插入指定数量的产品(产品的主键是自增列的)。
UpdateDiscreteCustomers 更新500条数据。 UPDATE 更新指定数量的客户。
DeleteDiscreteDetails 删除500条数据。 DELETE1 删除指定数量的订单明细。
DeleteDiscreteWarehouses 删除500条数据。 DELETE2 删除指定数量的仓库(仓库是复合主键)。

这里我们已经测试一个框架的增删改查,单个主键、复合主键、自增主键都有覆盖。为了公平我们将按顺序执行每个框架的测试,然后再重复执行多次。

测试结果

如下图所示为测试的结果,本次测试针对 每个框架运行了4次,结果中首先输出了每个框架每一次的运行结果,在最后的汇总中输出了所有框架的平均用时。

结果分析

首先我们需要强调的是以上测试忽略了一些先进ORM框架的优势,例如批量插入自增列数据时,所生成的编号会返回到原对象中。从如上图的测试结果可以看出在查询方面各个框架都是比较接近的,不过会随着数据量升高这个差异会升高,在插入、更新及删除操作中就差别比较大了。主要原因是在批量提交中各个框架是逐个语句提交,还是组合批量提交的差别,这里主要是实现SQL语句的不同所产生的差异。在查询方面ADO.NET+AutoMapper是性能最高的,这个没有争议,如果有疑问可以参考开头所发的例子中,本文没有测试这个项目是因为修改操作实现不理想。

后计

本文只把测试结果显示出来,没有结出任何结论,有兴趣的朋友可以从 Github 上下载代码来运行查看结果,后续还会持续更新加入更多框架进行测试。

原文地址:https://www.cnblogs.com/CarefreeXT/p/8728025.html

时间: 2024-10-08 10:13:56

Mego(1) - NET中主流ORM框架性能对比的相关文章

[java]序列化框架性能对比(kryo、hessian、java、protostuff)

序列化框架性能对比(kryo.hessian.java.protostuff) 简介:   优点 缺点 Kryo 速度快,序列化后体积小 跨语言支持较复杂 Hessian 默认支持跨语言 较慢 Protostuff 速度快,基于protobuf 需静态编译 Protostuff-Runtime 无需静态编译,但序列化前需预先传入schema 不支持无默认构造函数的类,反序列化时需用户自己初始化序列化后的对象,其只负责将该对象进行赋值 Java 使用方便,可序列化所有类 速度慢,占空间      

Mego(2) - NET主流ORM框架分析

接上文我们测试了各个ORM框架的性能,大家可以很直观的看到各个ORM框架与原生的ADO.NET在境删改查的性能差异.这里和大家分享下我对ORM框架的理解及一些使用经验. ORM框架工作原理 典型ORM框架实现 EF功能最强的ORM EF与EFCore缺陷 ORM框架工作原理 所有的ORM框架的工作原理都离不开下面这张图,只是每个框架的实现程度不同但是最终的目的是相同的. 如果是一个ORM框架那么一定会有上图中蓝色部分的这几个元素,无论是增删改查对于ORM一定是以对象为起点,使用对象构造出LINQ

几种流行Webservice框架性能对比

1摘要 开发webservice应用程序中离不开框架的支持,当open-open网站列举的就有很多种,这对于开发者如何选择带来一定的疑惑.性能Webservice的关键要素,不同的框架性能上存在较大差异,而当前在官方网站.网络资料中可以方便的找到各自框架的介绍,但是很少有针对不同框架性能测试数据.本文选择了比较流行几个框架: Apache Axis1.Apache Axis2.Codehaus XFire.Apache CXF.Apache Wink.Jboss  RESTEasy.sun JA

自己动手ab测了个ThinkPHP与CodeIgniter框架性能对比

PHP环境:Apache 2.4.10 + PHP 5.4.36 同样php输出代码 echo 'Hello Qzzm!'; 以下列出分别测试结果 一.CodeIgniter 2.2 This is ApacheBench, Version 2.3 <$Revision: 1604373 $>Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/Licensed to The Apache Softwar

微服务架构中主流的配置中心对比分析?

为什么需要配置中心 配置实时生效: 传统的静态配置方式要想修改某个配置只能修改之后重新发布应用,要实现动态性,可以选择使用数据库,通过定时轮询访问数据库来感知配置的变化.轮询频率低感知配置变化的延时就长,轮询频率高,感知配置变化的延时就短,但比较损耗性能,需要在实时性和性能之间做折中.配置中心专门针对这个业务场景,兼顾实时性和一致性来管理动态配置. 配置管理流程: 配置的权限管控.灰度发布.版本管理.格式检验和安全配置等一系列的配置管理相关的特性也是配置中心不可获取的一部分. 开源配置中心基本介

前端框架性能对比

运行性能对比: JSP+Servlet > Struts1 > SpringMvc > Struts2+freemarker >> Struts2+OGNL+值栈 但是开发效率上正好相反,要特别注意,SpringMvc和Struts2不相上下

3大主流NoSQL数据库性能对比测试报告

近日,知名独立基准测评机构Bankmark,针对目前市面上主流的NoSQL数据库SequoiaDB.MongoDB以及Cassandra三款NoSQL数据库产品做了性能对比测试并发布测试报告.在所有的测试中,三款NoSQL数据库产品的表现各有千秋,没有那款产品能在所有测试场景中完败对手,就整体表现而言SequoiaDB与Cassandra不相上下表现上佳,而MongoDB表现却不理想属于垫底的存在. 测试机构: Bankmark是一家德国的独立基准测评机构,业内著名的NoSQL性能测试团队. 测

Android中List循环遍历性能对比

在android开发中只要是列表式风格界面我们几乎都需要用到List来存放数据,在数量很少的List的话几乎任何一种循环遍历方式整体性能都无差别,但是当我们遇到数据量稍大的时候有必要考虑用哪种方式写起来比较高性能. 常见的有以下三种: 第一种 for (String s : tests) { // .... } 第二种 int size = tests.size(); for (int i = 0; i < size; i++) { tests.get(i); } 第三种 Iterator<S

序列化框架性能对比(kryo、hessian、java、protostuff)

简介:   优点 缺点 Kryo 速度快,序列化后体积小 跨语言支持较复杂 Hessian 默认支持跨语言 较慢 Protostuff 速度快,基于protobuf 需静态编译 Protostuff-Runtime 无需静态编译,但序列化前需预先传入schema 不支持无默认构造函数的类,反序列化时需用户自己初始化序列化后的对象,其只负责将该对象进行赋值 Java 使用方便,可序列化所有类 速度慢,占空间                   测试环境: 硬件信息: 16 Intel(R) Xeo