3

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

 3 years ago
source link: https://www.yangyanxing.com/article/orm-sql-performance.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

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

2022年4月11日
| python

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

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

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

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

@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语句查询

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 压测结果

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 在请求前后添加钩子时的压测结果

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的超时错误.

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

image-20220411174615699

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

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

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

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

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

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


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK