当返回json数据比较大时，api返回延迟很高

[nipeone]

一个大约6M的json内容，通过ResponseModel返回，大约需要3.5s。而用原生fastapi大约需要0.17s。初步判断是opera_log_middleware中的问题，因为将此中间件注释后返回延迟也降到0.17s左右。
test.json

[wu-clan]

我们会积极调查此事件，感谢反馈

[wu-clan]

这是我的测试代码：

@router.get('/test/lf')
async def get_lf():
    async with aiofiles.open('/Users/null/Downloads/test.json') as f:
        data = await f.read()
        import orjson
        data = orjson.loads(data)
    # return await response_base.success(data=data)
    return {'data': data}

此中间件的开启和关闭在两种返回方式响应时间上几乎没有差别

或者，你能提供更好的 MRE 用于我本地测试吗？

[nipeone]

最新的代码和我昨天测试的现象稍有不同，最新的代码OperaLogMiddleware确实没有差别，但GZIP插件的区别还蛮明显，还有三种结果返回形式的速度也有区别，我也继续跟踪哪里的问题，这是我的测试代码
file: api/v1/monitor/server.py

with open('/opt/test.json') as f:
    data = f.read()
    import orjson
    data = orjson.loads(data)

from backend.utils.serializers import MsgSpecJSONResponse
@router.get('/test/lf/a', summary='server 测试')
async def get_lf_a():

    return {'code':200, 'msg':'', 'data': data}

@router.get('/test/lf/b', summary='server 测试')
async def get_lf_b():

    return MsgSpecJSONResponse({'code':200, 'msg':'', 'data': data})

@router.get('/test/lf/c', summary='server 测试')
async def get_lf_c():

    return await response_base.success(data=data)

test.py

import requests
import time
import orjson

retry_count = 10

def retry(num:int):
    def iter(func:callable):
        def wrapper(x:str):
            for _ in range(num):
                func(x)
        return wrapper
    return iter

@retry(retry_count)
def handler(x):
    response = requests.get(f"http://127.0.0.1:8000/api/v1/monitors/server/test/lf/{x}")
    j = orjson.loads(response.text)
    return j

def main():
    t1=time.time()
    handler('a')
    t2=time.time()
    handler('b')
    t3=time.time()
    handler('c')
    t4=time.time()
    print(f'direct return        cost:{(t2-t1)/retry_count:.3f}s')
    print(f'MsgSpecJSONResponse  cost:{(t3-t2)/retry_count:.3f}s')
    print(f'ResponseModel        cost:{(t4-t3)/retry_count:.3f}s')

if __name__ == '__main__':
    main()

三种返回延迟各不相同
MIDDLEWARE_GZIP: bool = False
MIDDLEWARE_OPERA:bool = True

direct return        cost:1.898s
MsgSpecJSONResponse  cost:0.227s
ResponseModel        cost:2.136s

MIDDLEWARE_GZIP: bool = False
MIDDLEWARE_OPERA:bool = False

direct return        cost:1.776s
MsgSpecJSONResponse  cost:0.197s
ResponseModel        cost:2.019s

MIDDLEWARE_GZIP: bool = True
MIDDLEWARE_OPERA:bool = False

direct return        cost:3.300s
MsgSpecJSONResponse  cost:1.731s
ResponseModel        cost:3.548s

MIDDLEWARE_GZIP: bool = True
MIDDLEWARE_OPERA:bool = True

direct return        cost:3.371s
MsgSpecJSONResponse  cost:1.786s
ResponseModel        cost:3.622s

[wu-clan]

我将尝试使用 anyio 或 asyncio 方法替换 OperaLogMiddleware 中的 task，这里的性能损耗相对较小，因为大型 json 返回并没有到处可见

令我感到惊讶的是，MsgSpecJSONResponse 已经用作 fastapi 的默认序列化器，但再次使用，竟会有如此大的速度提升

相比之下，更应该考虑 GZIP 中间件的性能损耗，如此之大

[nipeone]

有简单做过一个测试，MsgSpecJSONResponse作为默认序列化器貌似没起什么作用。

[wu-clan]

查看性能讨论 #265，我想直接使用 MsgSpecJSONResponse 加速是有道理的，因为在 MsgSpecJSONResponse 作为默认序列器起生效之前，性能损失可能来自 fastapi 默认的 pydantic 序列化，如果添加一个 orjson 返回的测试，或许对比性也将存在

[wu-clan]

GZIP 中间件在 dev 模式中，用作响应压缩，线上模式，通常采用 nginx 实施，如果它的影响如此之大，我认为完全可以删除它，因为 dev 模式下压缩意义不大，并且，此中间件内部存在同步 io 操作，这可能是重要影响因素

[nipeone]

查看性能讨论 #265，我想直接使用 MsgSpecJSONResponse 加速是有道理的，因为在 MsgSpecJSONResponse 作为默认序列器起生效之前，性能损失可能来自 fastapi 默认的 pydantic 序列化，如果添加一个 orjson 返回的测试，或许对比性也将存在

关于这一点稍有不明白，default_response_class=MsgSpecJSONResponse的作用不是指明序列化器吗？fastapi还会再调用pydantic序列化吗？还是说数据对象在进MsgSpecJSONResponse之前会受到pydantic的validation？

[wu-clan]

default_response_class 只用作最终返回，在此之前，fastapi 会在内部提前序列化数据（pydantic / jsonable_encoder）再返回

如果接口直接返回序列化后的数据（字典），那么 fastapi 在内部的提前序列化就变为了简单地处理字典数据

从目前的测试结果看，直接返回大字典和返回 pydantic 模型，差异很小，但是返回 MsgSpecJSONResponse 大字典数据速度竟如此之快？我不确定其中的细节，猜测应该测试 pydantic，msgspec 对大字典的处理速度比较

如果确认细节，我们可能会添加一个 response_base.fast_success() 方法（方法名暂定），用于快速响应较大数据

[nipeone]

that's great! 再把BackgroundTask(OperaLogService.create, obj_in=opera_log_in)改为anyio或者asyncio的后台执行任务，性能损耗就很小了

[wu-clan]

在原有的接口基础上添加此接口：

@router.get('/test/lf/d')
async def get_lf_d():
    return ORJSONResponse({'code': 200, 'msg': '', 'data': data})

测试代码：

import asyncio

import httpx
import time
import orjson

retry_count = 10


def retry(num: int):
    def _iter(func: callable):
        async def wrapper(x: str):
            for _ in range(num):
                await func(x)

        return wrapper

    return _iter


@retry(retry_count)
async def handler(x):
    async with httpx.AsyncClient(verify=False, timeout=10) as client:
        response = await client.get(f"http://127.0.0.1:8000/api/v1/monitors/server/test/lf/{x}")
        j = orjson.loads(response.text)
        return j


async def main():
    t1 = time.time()
    await handler('a')
    t2 = time.time()
    await handler('b')
    t3 = time.time()
    await handler('c')
    t4 = time.time()
    await handler('d')
    t5 = time.time()
    print(f'direct return        cost:{(t2 - t1) / retry_count:.3f}s')
    print(f'MsgSpecJSONResponse  cost:{(t3 - t2) / retry_count:.3f}s')
    print(f'ResponseModel        cost:{(t4 - t3) / retry_count:.3f}s')
    print(f'ORJSONResponse       cost:{(t5 - t4) / retry_count:.3f}s')


if __name__ == '__main__':
    asyncio.run(main())

MIDDLEWARE_GZIP: bool = False
MIDDLEWARE_OPERA: bool = True (BackgroundTask)

direct return        cost:2.217s
MsgSpecJSONResponse  cost:0.225s
ResponseModel        cost:2.335s
ORJSONResponse       cost:0.223s

MIDDLEWARE_GZIP: bool = False
MIDDLEWARE_OPERA: bool = True (asyncio task)

direct return        cost:1.955s
MsgSpecJSONResponse  cost:0.225s
ResponseModel        cost:2.264s
ORJSONResponse       cost:0.229s

MIDDLEWARE_GZIP: bool = False
MIDDLEWARE_OPERA: bool = True (anyio task)

direct return        cost:2.066s
MsgSpecJSONResponse  cost:0.223s
ResponseModel        cost:2.343s
ORJSONResponse       cost:0.224s

[wu-clan]

最终决案（拟定）：

1. 删除 MIDDLEWARE_GZIP 中间件
2. MIDDLEWARE_OPERA 的性能损耗可忽略不计
3. 替换 MIDDLEWARE_OPERA 为 asyncio task
4. 添加基于 MsgSpecJSONResponse 的 response_base.fast_success() 返回方法