重要补充说明(放在最前面)

博客中EFCore测试结果比其它ORM快的原因

涉及博客《ORM增删改查并发性能测试》《ORM增删改查并发性能测试2》《.NET 6 EFCore WebApi 使用 JMeter 进行吞吐量测试》

测试代码中EFCore的多字段排序写法不正确，导致生成的SQL不正确，SQL中只有Id排序，没有CreateTime字段的排序！

EFCore不正确的多字段排序写法

string remark = "测试";
int id = 20;

var list = await _db.Set<SysUser>().AsNoTracking()
    .Where(t => t.Id > id && t.RealName.Contains(remark))
    .OrderByDescending(t => t.CreateTime)
    .OrderBy(t => t.Id).Skip(1800).Take(200).ToListAsync();

EFCore正确的多字段排序写法

string remark = "测试";
int id = 20;

var list = await _db.Set<SysUser>().AsNoTracking()
    .Where(t => t.Id > id && t.RealName.Contains(remark))
    .OrderByDescending(t => t.CreateTime)
    .ThenBy(t => t.Id).Skip(1800).Take(200).ToListAsync();

重新测试EFCore

测试命令：

第一轮：

跟其它ORM差不多。

第二轮：

跟其它ORM差不多。

代码：

.NET 6 EFCore WebApi 使用 JMeter 进行吞吐量测试

开发环境

VS2022
.NET 6

测试环境

测试工具

接口压力测试工具：JMeter

数据库

MySQL 5.7
数据库和WebApi服务在同一台服务器上，JMeter在本人笔记本上。

测试设置

200个线程并发，每个线程循环50次，共10000次请求。

接口代码

模糊查询、排序、分页查询第10页200条数据，参数化查询条件。

EFCore (第一轮请求)，测试结果

服务程序部署到测试服务器上测试，连接MySql数据库。

吞吐量

只有200多

每个请求响应时间

最长5秒多

EFCore (第一轮请求结束后，20秒内进行第二轮请求)，测试结果

服务程序部署到测试服务器上测试，连接MySql数据库。
经过第一轮10000个请求的充分预热，取第二轮10000个请求的测试结果。

吞吐量

1200多

每个请求响应时间

不到50毫秒

线程占用

最大达到143个线程

EFCore (第一轮请求结束后，20秒后进行第二轮请求)，测试结果

吞吐量

1200

每次请求响应时间

100毫秒

线程占用

只有50多个线程

使用FactoryStartNew. StartNewThread

查询代码

FactoryStartNew. StartNewThread代码

使用FactoryStartNew. StartNewThread (第一轮请求)，测试结果

服务程序部署到测试服务器上测试，连接MySql数据库。

吞吐量

不到200

每个请求响应时间

最长33秒

使用FactoryStartNew. StartNewThread (第一轮请求结束后，20秒内进行第二轮请求)，测试结果

吞吐量

1000多

每个请求响应时间

200毫秒以内

线程占用

高达260多个线程

使用FactoryStartNew. StartNewThread (第一轮并发请求结束后，20秒后进行第二轮请求)，测试结果

吞吐量

只有200多

每个请求响应时间

最长达到了30秒
在等待创建线程，.NET默认线程池，1秒才增加一个线程

线程占用

高达230多个线程

对比SqlSugar

同样的数据库，同样的数据，同样的查询，同样的JMeter测试设置，同样取第二轮测试结果。

吞吐量

395

每个请求响应时间

500毫秒

对比FreeSql

同样的数据库，同样的数据，同样的查询，同样的JMeter测试设置，同样取第二轮测试结果。

吞吐量

408

每个请求响应时间

不到500毫秒

对比Dapper.LiteSql

吞吐量

480多

每个请求响应时间

400多毫秒

结论

1. EFCore优秀，吞吐量和响应时间都非常优秀。

2. 使用FactoryStartNew. StartNewThread，能用，但有问题。

3. 如果觉得自己的ORM没问题，那就没有问题了，谁没事闲的做这种测试，慢一点不会死人，用户多了并发多了就加机器，作者和用户永远也不会知道，明明可以达到1000的吞吐量，却一直用的280吞吐量的ORM。

4. 比EFCore慢不丢人。

5. 不要说代码怎么写的，我要看测试结果。

测试工程地址

https://gitee.com/s0611163/Net6WebApiPerformanceTest


本文转载自：https://www.cnblogs.com/s0611163/p/16711330.html