Gdao—orm框架性能压测 gdao+gorm+sqlx+原生sql执行

本文重点对gdao的各个模块进行基准压力测试，同时压测 同类型orm框架如 gorm，sqlx 与 不使用第三方库时直接执行原生sql执行等情况的执行效率

gdao使用文档
压测程序地址
orm连接mysql场景的压测数据

增加执行时间后的压测数据

Msql场景中的压测数据分析

执行原生 SQL 压测数据

  • 执行时间: 276895 ns/op 至 294923 ns/op
  • 内存使用:  5200 B/op
  • 分配次数:  105 allocs/op

gdao压测数据

1. 标准化结构体 (gdao_struct)
  • 执行时间: 200096 ns/op 至 209589 ns/op
  • 内存使用:  20742 B/op
  • 分配次数:  490 allocs/op
2. gdao执行原生sql并映射为结构体 (gdao_sql)
  • 执行时间: 190555 ns/op 至 200864 ns/op
  • 内存使用:  17902 B/op
  • 分配次数:  395 allocs/op
3. gdao执行原生sql并映射为Databean (gdao_databean)
  • 执行时间: 176418 ns/op 至 192119 ns/op
  • 内存使用:  11121 B/op
  • 分配次数:  316 allocs/op
4. gdao xml 映射 (gdao_mapper_struct & gdao_mapper_databean)
  • 执行时间: 211467ns/op 至 214123 ns/op (struct)，198357 ns/op 至 201094 ns/op (databean)
  • 内存使用:  20022 B/op (struct)， 16130 B/op (databean)
  • 分配次数:  509 allocs/op (struct)，411 allocs/op (databean)

gorm压测数据

1. 结构化执行 (gorm_struct)
  • 执行时间: 346364 ns/op 至 401958 ns/op
  • 内存使用:  16699 B/op
  • 分配次数:  251 allocs/op
2. gorm执行原生sql并映射为结构体 (gorm_sql)
  • 执行时间: 316106 ns/op 至 337591 ns/op
  • 内存使用: 14041 B/op
  • 分配次数: 208 allocs/op

sqlx压测数据

1. sqlx 执行原生sql并映射为结构体 (sqlx_sql)
  • 执行时间: 291815 ns/op 至 315906 ns/op
  • 内存使用:  8605 B/op
  • 分配次数:  123 allocs/op


分析与说明：

  • 由于gdao包含了标准化结构体，原生SQL执行，XML映射等多个模块，并相互独立，适用不同场景，因此分别压测
  • gorm主要包含结构体映射和原生SQL执行映射
  • sqlx功能相对较少，主要为原生SQL执行映射为结构体


Intel(R) Core(TM) i5-1035G1 CPU @ 1.00GHz 压测环境，数据统计如下

  1. gdao的执行效率为 200000 ns/op左右，大部分执行效率 200000 ns/op以下
  2. 原生SQL执行效率为 280000 ns/op 左右，即直接调用驱动执行SQL的效率
  3. gorm的执行效率为 310000 ns/op — 401958 ns/op，直接执行SQL并映射为结构体更快
  4. sqlx的执行效率为 290000 ns/op — 315906 ns/op


可以看到，gdao的各个模块的执行效率远高于其他框架和直接原生SQL执行的效率，其中性能最高的方式是：执行sql并映射为Databean的方式，如下：

gdao.ExecuteQueryBeans(sqlstr, args...)

测试数据显示，gdao的性能几乎是gorm的两倍，效率比直接调用驱动接口执行SQL的效率 高30%以上；sqlx效率接近原生SQL执行，gorm的结构化的执行效率比较差，特别是增加压测时间后，执行响应下降到 401958 ns/op。

说明：gdao之所以比直接调用驱动接口执行SQL更高效，是基于gdao的底层优化，包括对象池，对象复用等优化策略。



orm连接 postgreSQL场景的压测数据

分析与说明


在 Intel(R) Core(TM) i5-1035G1 CPU @ 1.00GHz 环境中，压测数据统计如下

  1. gdao的执行效率为 129751 ns/op — 146315 ns/op
  2. 原生SQL执行效率为  246952 ns/op — 267730 ns/op
  3. gorm的执行效率为 145668 ns/op — 153753 ns/op
  4. sqlx的执行效率为 249560 ns/op — 276177 ns/op


在postgreSQL  出现不同的情况

  1. gdao的执行效率同样最佳，执行效率几乎是直接调用原生SQL的两倍
  2. gorm在postgreSQL中的执行效率比在mysql中呈现极大提高，几乎接近gdao的效率
  3. sqlx的执行效率同样接近原生SQL


gorm在postgreSQL中的执行效率突然提升到 接近gdao效率的原因

由于只是数据库不同，gorm出现性能突然飙升的情况比较奇怪，我查看了gorm的实现，发现gorm并没有针对postgreSQL做特别的优化

但是gorm内置的驱动 “gorm.io/driver/postgres” 并没有使用官方驱动，而是使用了 "github.com/jackc/pgx" ,我查看了 github.com/jackc/pgx的实现，发现它的确做了优化，在执行sql是，pgx专门对SQL预编译做了优化。 因此gorm在postgreSQL中出现性能提升。总结如下：

PostgreSQL 中，gorm 的性能提升主要是因为其使用的 jackc/pgx 驱动进行了以下几方面的优化：

  • SQL 预编译：减少每次查询的编译时间。
  • 连接池管理：复用连接，减少连接建立和断开的时间。
  • 批处理和流式处理：减少网络往返次数。
说明：

jackc/pgx 的优化策略，gdao已经做了类似的优化，适用各种数据库，无需依赖驱动，因此gdao在压测中，依然使用官方驱动。