测试报告数据获取,一开始定义的时候设计了两个接口,获取报告概要信息和获取报告的用例详细信息,使用了一段时间后,发现获取报告详细信息这个接口变得很慢
开始定位问题的时候初步判断是因为report的表数据达到30G导致数据查询慢,增加表的索引和增加测试报告按照策略定期清理的功能,稍有缓解,但是仍有小伙伴反馈打开测试报告需要较长的时间,不过该问题是重要不紧急,一直搁置没有处理
前端时间有小伙伴反馈,他们有一个全量执行的测试报告打不开,发布需要,急急急,好啦。需要加急处理该问题
定位发现这个测试报告的用例数2576
条,在前端打开这个报告的详情页面等待5分钟仍未打开报告,而且最终以打开超时失败告终
那时间究竟消耗在哪些部分?
在本地开发环境后台服务定位,发现有两个部分耗时很严重
一个是从数据库拉取执行的测试用例详细(一次性拉取所有数据,尴尬),一个是处理数据耗时(各种json.loads()
)
string进行json处理时,有些数据处理失败,如
import json
print(json.loads("{'a':'b'}"))
异常信息
Traceback (most recent call last):
File "/Users/lluozh/work/git/swapi/xyz.py", line 39, in <module>
print(json.loads("{'a':'b'}"))
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/json/__init__.py", line 348, in loads
return _default_decoder.decode(s)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/json/decoder.py", line 353, in raw_decode
obj, end = self.scan_once(s, idx)
json.decoder.JSONDecodeError: Expecting property name enclosed in double quotes: line 1 column 2 (char 1)
json5可以处理
import json5
print(json5.loads("{'a':'b'}"))
输出
{'a': 'b'}
但是有个问题,json5处理的效率远不如json,处理时间是json的二十倍不止
看到有人针对json序列化与反序列化速度对比(按总时间排序:测试数据100 * 10000)
ujson 序列化: 2.084 反序列化: 1.157 总时间: 3.241
yajl 序列化: 1.910 反序列化: 1.970 总时间: 3.880
cjson 序列化: 3.305 反序列化: 1.328 总时间: 4.632
simplejson 序列化: 10.279 反序列化: 4.658 总时间: 14.937
stdlib json 序列化: 7.013 反序列化: 8.594 总时间: 15.607
问题是以上库均无法处理上面举证的许多异常情况
写个方法做处理
def json_loads(json_str,extra=False):
"""
将字符串类型的json格式处理
:param json_str:
:param extra: 是否需要额外处理信息
:return:
"""
try:
# 首先ujson,处理效率高
return ujson.loads(json_str)
except:
try:
# 使用json处理
return json.loads(json_str)
except:
try:
# json5.load,增加额外信息的处理
return json5.loads(json_str)
except:
if extra:
try:
# 处理json的字符串中有True或False的特殊情况
return json5.loads(json_str.replace("True", "true").replace("False", "false"))
except:
pass
return json_str
这样可以提高效率,但是用例中仍存在部分json处理不了的信息,导致这部分的时间并未本质的降低,而且这样修改也并不可控
那看看拉取数据库中用例详细信息这块是否可以降低时间,首先拉取2000+
条用例信息,数据大小达到300M,一次性load的话,一个是等待时间久,一个是load内存如果数据量更大或者多个用户同时在拉取测试报告时可能会导致服务直接出问题
那是否可以测试报告中每条用例拉取一次呢?但是这样降低时间有效
那是否有更好的方式解决获取测试报告时间过长的问题?
其实可以在前端打开报告时,仅仅反馈概要信息和用例列表概要信息,用户在打开某条用例时,前端再根据相关的参数获取该用例执行的详细信息即可,这样可以解决以上问题
按照上面说的方式修改,发现500+
条用例的报告可以在30s
内打开,2000+
条用例的报告可以在1min
左右打开,搞定!!!