使用ORM与原始SQL的性能对比

2022-04-11 约 1360 字预计阅读 3 分钟

最近使用号称 python web 框架中性能最为强悍的框架 sanic , 搭建了项目的基础环境与项目框架,但是在是否使用ORM 的时候犯了选择困难综合症了,对于一个追求性能的框架,在使用了 ORM 以后必定会对性能有些影响,但是影响究竟有多大呢? ORM 的存在也是有它的理由的, 那么它的优点能否消除它在性能上的损耗呢?

我主要使用了两个ORM, 与其说是两个,其实也就是一个 sqlalchemy ,但是这里的sqlalchemy 是两个不同库中的,一个是aiomysql中自带的sqlalchemy, 我简称aiomysql.sa, 一个是大名鼎鼎的sqlalchemy 库.

数据准备,就是一个简单的user表,里面有id, username.

我是在查看 sanic 教程时, 它有提到如何使用ORM, 它是用中间件的方式在处理每一个请求之前使用sessionmaker 创建了一个session 挂到请求的上下文中,并且在结束请求时再将session 关掉

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
@app.middleware("request")
async def inject_session(request):
    request.ctx.session = sessionmaker(bind, AsyncSession, expire_on_commit=False)()
    request.ctx.session_ctx_token = _base_model_session_ctx.set(request.ctx.session)


@app.middleware("response")
async def close_session(request, response):
    if hasattr(request.ctx, "session_ctx_token"):
        _base_model_session_ctx.reset(request.ctx.session_ctx_token)
        await request.ctx.session.close()

我隐约的感觉到这种方式可能会带来一些性能上的损耗,如果请求量很大的时候,每个请求都要重新创建一个session 用于处理数据库,然后再释放掉,那么如果该请求没有进行数据库操作的时候,岂不是浪费了? 并且大量请求到来的时候，系统也要花费一定的资源用于这种创建与关闭，且这些 session 无法共用, 其实也不能说不能共用,我尝试过将session 挂到app.ctx 下, 也是可以用的,但是会有一个问题,如果某个请求需要比较长的时间,比如说5秒钟,那么下一个请求如果想要使用该session, 那么就要等到之前的请求结束才可以复用.

所以以下的压力测试分为两个阶段,第一是不存在请求与响应中间件,这时就只对使用aiomysql 库来进行压力测试.

第二阶段是在请求与响应前后加上中间件,这里会有三个测试.

以下是使用wrk 进行的压测, 10个线程,2000个连接, 压测10秒钟得到的结果

服务端开户4个workers, 使用uvloop

使用纯sql语句查询

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
10 threads and 2000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   558.19ms  200.95ms   1.32s    59.15%
    Req/Sec   344.02    230.72     1.76k    68.29%
  Latency Distribution
     50%  583.50ms
     75%  707.32ms
     90%  819.57ms
     99%    1.00s
  33488 requests in 10.03s, 3.74MB read
Requests/sec:   3337.65
Transfer/sec:    381.35KB

使用aiomysql.sa 压测结果

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
10 threads and 2000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   905.52ms  206.57ms   1.40s    65.57%
    Req/Sec   231.70    202.40     1.12k    72.10%
  Latency Distribution
     50%  909.34ms
     75%    1.05s
     90%    1.17s
     99%    1.33s
  20031 requests in 10.03s, 2.24MB read
Requests/sec:   1997.86
Transfer/sec:    228.27KB

以下为在请求与响应前后添加 session 钩子的压测结果

使用 sqlalchemy 在请求前后添加钩子时的压测结果

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
10 threads and 2000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   638.07ms  632.25ms   2.00s    82.41%
    Req/Sec   148.81     61.53   380.00     71.04%
  Latency Distribution
     50%  126.46ms
     75%    1.15s
     90%    1.54s
     99%    1.96s
  14094 requests in 10.02s, 1.57MB read
  Socket errors: connect 0, read 0, write 0, timeout 2510
Requests/sec:   1406.67
Transfer/sec:    160.72KB

这次还有timeout的超时错误.

之后的结果就不详细展示了,我总结了一张表格

可以简单的得到以下结论:

单纯的以吞吐量为衡量指标的话,纯 SQL 是添加session 的 sqlalchemy 的2.37倍
在请求前后添加 session 会对性能有一些影响,大概有20%的性能损耗.

以上只是单纯的从吞吐量来比较纯SQL 与 ORM 之间的性能差异,其实有这样的性能差异也很好理解, ORM 会做一些对象的解析工作.

就我个人而言,我还是比较喜欢直接用SQL来进行查询, 我总觉得 ORM 还得熟悉它的各种查询条件,但是 ORM 对于后期切换数据库来说很方便,但是又有多少项目会切换数据库呢?

ORM 对于一些比较复杂的sql语句就更加难以控制.

但是如果你只是做一个很小的系统,请求量没有那么大的时候,我觉得使用ORM或者SQL应该都可以.

文章标题: 使用ORM与原始SQL的性能对比
本文作者: 杨彦星
本文链接: https://www.yangyanxing.com/article/orm-sql-performance.html
版权声明: 本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。非商业转载请注明出处（作者，原文链接），商业转载请联系作者获得授权。

目录

使用ORM与原始SQL的性能对比