今天在做一个热门赛事列表查询的接口压测
http://192.168.10.98:8094/match/page?matchType=0&matchTime=0&matchStatus=0&matchName=
和开发讨论,说matchName字段采用like匹配,会导致查询慢,建议采用http://192.168.10.98:8094/match/page?matchStatus=0压测
最初的压测效果如下:
http://192.168.10.98:8094/match/page?matchStatus=0
发现
http://192.168.10.98:8094/match/page?matchType=0&matchTime=0&matchStatus=0&matchName=&page=1&rows=20
压测场景如下:查询热门赛事列表
压测脚本如下
压测前:
200线程并发:平均tps大约207左右,平均耗时1.3s
第一轮优化:
查看原始sql:
优化后
性能优化将近提升2倍,但是性能还没有达到理想值
通过监控mysql服务器的资源消耗:
发现mysql的资源基本完全消耗完毕,所以目前优化空间在mysql上
通过监控mysql慢查询
SELECT
T2.*
FROM (
SELECT
@area_id AS child_id,
(SELECT @area_id := parent_id FROM
dict_area WHERE AREA_ID = child_id) AS
parent_id,
(@area_level :=
@area_level + 1) AS area_level
FROM
(SELECT @area_id := 11959,
@area_level := 0) v,
dict_area h
WHERE @area_id <>
0 ) T1
JOIN dict_area T2
ON T1.child_id = T2.AREA_ID
where
T2.lang_type='zh_CN'
ORDER BY T1.area_level ASC;
这条sql采用了递归查询,普通执行很快,但是高并发就很慢
通话程序代码优化,重新打包压测,性能测试结果tps提升一倍多
此时,http://192.168.10.98:8094/match/page?matchStatus=0 只带matchStatus字段,压测效果比较理想,但是随后再加上
http://192.168.10.45:8094/match/page?matchStatus=0&page=1&rows=20
性能还是回到tps平均在350左右
所以得持续分析优化