基于 Yii 2 的 ActiveRecord,在运行期间,Redis的CPU使用率为100%的分析、解决

1、在2017-06-18 19:36:00,即比赛开始的时候,应用的响应时间为51.8ms,响应时间正常,如图1

在2017-06-18 19:36:00,即比赛开始的时候,应用的响应时间为51.8ms,响应时间正常

图1

2、在整个足球比赛期间,响应时间呈线性不断增加,在2017-06-18 20:30:00 至 2017-06-18 20:40:00,响应时间下降,是因为此时比赛处于中场休息期间,基本上发送至服务器的比赛数据无变化,因此处理逻辑简单,如图2

在整个足球比赛期间,响应时间呈线性不断增加,在2017-06-18 20:30:00 至 2017-06-18 20:40:00,响应时间下降,是因为此时比赛处于中场休息期间,基本上发送至服务器的比赛数据无变化,因此处理逻辑简单

图2

3、在2017-06-18 21:25:00,即比赛即将结束的时候,应用的响应时间为2320ms,业务目标所要求的平均响应时间为150ms,因此性能无法满足业务要求,如图3

在2017-06-18 21:25:00,即比赛即将结束的时候,应用的响应时间为2320ms,业务目标所要求的平均响应时间为150ms,因此性能无法满足业务要求

图3

4、在APM的Transaction trace中,可以发现在一次响应时间为5710 ms的请求中,Redis相关的操作就消耗了4390 ms,占用的比例为77%,httpclient是调用了另一个接口,其接口中也使用了Redis的,因此,分析结果为Redis为性能瓶颈所在,如图4

在APM的Transaction trace中,可以发现在一次响应时间为5710 ms的请求中,Redis相关的操作就消耗了4390 ms,占用的比例为77%,httpclient是调用了另一个接口,其接口中也使用了Redis的,因此,分析结果为Redis为性能瓶颈所在

图4

5、在APM的Transaction trace的 Trace details中,发现 shujujiexi/models/redis/GamePlayerData::gamePlayerDataByShuJuJieXi 所消耗时间占用的比例为 57.25%,如图5

在APM的Transaction trace的 Trace details中,发现 shujujiexi/models/redis/GamePlayerData::gamePlayerDataByShuJuJieXi 所消耗时间占用的比例为 57.25%

图5

6、继续展开,直到无法展开为止,发现 yii/redis/Connection::parseResponse ,需要分析其运行机制,如图6

继续展开,直到无法展开为止,发现 yii/redis/Connection::parseResponse ,需要分析其运行机制

图6

7、在阿里云监控中,在2017-06-18 19:36:00,即比赛开始的时候,Redis的CPU使用率为1.9%,如图7

在阿里云监控中,在2017-06-18 19:36:00,即比赛开始的时候,Redis的CPU使用率为1.9%

图7

8、在整个足球比赛期间,在阿里云监控中,Redis的CPU使用率呈线性不断增加,在2017-06-18 20:30:00 至 2017-06-18 20:40:00,Redis的CPU使用率下降,是因为此时比赛处于中场休息期间,基本上发送至服务器的比赛数据无变化,因此处理逻辑简单,整个曲线与响应时间完全成正比关系,如图8

在整个足球比赛期间,在阿里云监控中,Redis的CPU使用率呈线性不断增加,在2017-06-18 20:30:00 至 2017-06-18 20:40:00,Redis的CPU使用率下降,是因为此时比赛处于中场休息期间,基本上发送至服务器的比赛数据无变化,因此处理逻辑简单,整个曲线与响应时间完全成正比关系

图8

9、在阿里云监控中,在2017-06-18 21:27:00,即比赛即将结束的时候,Redis的CPU使用率为100%,如图9

在阿里云监控中,在2017-06-18 21:27:00,即比赛即将结束的时候,Redis的CPU使用率为100%

图9

10、在阿里云监控中,在2017-06-18 21:28:00,即比赛即将结束的时候,Redis的已用连接数为54个,达到峰值,如图10

在阿里云监控中,在2017-06-18 21:28:00,即比赛即将结束的时候,Redis的已用连接数为54个,达到峰值

图10

11、现在需要分析究竟是何原因导致Redis的CPU使用率为100%了,在APM的Transaction trace中,发现 yii/redis/ActiveRecord::deleteAll 所消耗时间占用的比例为 78%,如图11

现在需要分析究竟是何原因导致Redis的CPU使用率为100%了,在APM的Transaction trace中,发现 yii/redis/ActiveRecord::deleteAll 所消耗时间占用的比例为 78%

图11

12、在APM的Transaction trace的 Trace details中,发现 Application code (in yii/redis/ActiveRecord::deleteAll) 最为消耗时间,基本上可以确定ActiveRecord相关的操作为导致Redis的CPU使用率为100%的根本原因了,如图12

在APM的Transaction trace的 Trace details中,发现 Application code (in yii/redis/ActiveRecord::deleteAll) 最为消耗时间,基本上可以确定ActiveRecord相关的操作为导致Redis的CPU使用率为100%的根本原因了

图12

13、在pro环境,准备实现一个典型请求的2个版本,第1个版本的ActiveRecord相关的操作基本上为查询、修改,第2个版本的ActiveRecord相关的操作基本上为查询、插入,以便于确认当某个ActiveRecord模型中的key数量过多时,是否会提升Redis的CPU使用率,先清空Redis,之后定时任务所生成的Redis数据,key的数量为3170,如图13

在pro环境,准备实现一个典型请求的2个版本,第1个版本的ActiveRecord相关的操作基本上为查询、修改,第2个版本的ActiveRecord相关的操作基本上为查询、插入,以便于确认当某个ActiveRecord模型中的key数量过多时,是否会提升Redis的CPU使用率,先清空Redis,之后定时任务所生成的Redis数据,key的数量为3170

图13

14、在pro环境,请求的第1个版本运行2个小时之后,Redis数据,key的数量为3220,仅增加了50个key,如图14

在pro环境,请求的第1个版本运行2个小时之后,Redis数据,key的数量为3220,仅增加了50个key

图14

15、在pro环境,在整个典型请求的运行期间,在阿里云监控中,Redis的CPU使用率最高为2.6%,在 2017-06-27 16:50:00 之后,Redis的CPU使用率维持在0.6%,是因为此时,基本上发送至服务器的比赛数据无变化,因此处理逻辑简单,如图15

在pro环境,在整个典型请求的运行期间,在阿里云监控中,Redis的CPU使用率最高为2.6%,在 2017-06-27 16:50:00 之后,Redis的CPU使用率维持在0.6%,是因为此时,基本上发送至服务器的比赛数据无变化,因此处理逻辑简单

图15

16、在pro环境,在整个典型请求的运行期间,响应时间基本上保持稳定,最大响应时间为266ms,此请求的业务目标在生产环境上所要求的平均响应时间为200ms,因此性能满足业务要求,在 2017-06-27 16:50:00 之后,响应时间下降,是因为此时,基本上发送至服务器的比赛数据无变化,因此处理逻辑简单,如图16

在pro环境,在整个典型请求的运行期间,响应时间基本上保持稳定,最大响应时间为266ms,此请求的业务目标在生产环境上所要求的平均响应时间为200ms,因此性能满足业务要求,在 2017-06-27 16:50:00 之后,响应时间下降,是因为此时,基本上发送至服务器的比赛数据无变化,因此处理逻辑简单

图16

17、先清空Redis,之后定时任务所生成的Redis数据,key的数量为2909,如图17

先清空Redis,之后定时任务所生成的Redis数据,key的数量为2909

图17

18、在pro环境,请求的第2个版本运行2个小时之后,Redis数据,key的数量为89840,增加了86931个key,如图18

在pro环境,请求的第2个版本运行2个小时之后,Redis数据,key的数量为89840,增加了86931个key

图18

19、请求的第2个版本所操作的Redis模型的key的数量为79527,如图19

请求的第2个版本所操作的Redis模型的key的数量为79527

图19

20、在pro环境,请求的第2个版本,在整个典型请求的运行期间,在阿里云监控中,Redis的CPU使用率最高为66.8%,如图20

在pro环境,请求的第2个版本,在整个典型请求的运行期间,在阿里云监控中,Redis的CPU使用率最高为66.8%

图20

21、基于当前分析结果,已经可以确定当ActiveRecord操作的某个模型的key的数量过大时,Redis的CPU使用率会大幅度提升,不过是由于查询还是插入导致的,需要进一步确认,代码,如图21

基于当前分析结果,已经可以确定当ActiveRecord操作的某个模型的key的数量过大时,Redis的CPU使用率会大幅度提升,不过是由于查询还是插入导致的,需要进一步确认,代码

图21

22、修改查询方案,将count(‘id’)调整为exists(),即查询模型中满足条件的所有key调整为查询模型中满足条件的1个key,代码,如图22

修改查询方案,将count('id')调整为exists(),即查询模型中满足条件的所有key调整为查询模型中满足条件的1个key,代码

图22

23、不清空Redis,在pro环境,请求的第3个版本所操作的Redis模型的key的数量为81277,如图23

不清空Redis,在pro环境,请求的第3个版本所操作的Redis模型的key的数量为81277

图23

24、在pro环境,请求的第3个版本,在整个典型请求的运行期间,在阿里云监控中,Redis的CPU使用率最高为11.8%,如图24

在pro环境,请求的第3个版本,在整个典型请求的运行期间,在阿里云监控中,Redis的CPU使用率最高为11.8%

图24

25、基于当前分析结果,已经可以确定当ActiveRecord操作的某个模型的key的数量过大时,Redis的CPU使用率会大幅度提升,并且是与查询的关联性最大,不过查询与插入的性能对比,需要进一步确认,代码,注释掉查询,只保留插入操作,如图25

基于当前分析结果,已经可以确定当ActiveRecord操作的某个模型的key的数量过大时,Redis的CPU使用率会大幅度提升,并且是与查询的关联性最大,不过查询与插入的性能对比,需要进一步确认,代码,注释掉查询,只保留插入操作

图25

26、不清空Redis,在pro环境,请求的第4个版本所操作的Redis模型的key的数量为81947,如图26

不清空Redis,在pro环境,请求的第4个版本所操作的Redis模型的key的数量为81947

图26

27、在pro环境,请求的第4个版本,在整个典型请求的运行期间,在阿里云监控中,Redis的CPU使用率最高为2.2%,如图27

在pro环境,请求的第4个版本,在整个典型请求的运行期间,在阿里云监控中,Redis的CPU使用率最高为2.2%

图27

28、将count()调整为exists()以提升查询性能,如图28

将count()调整为exists()以提升查询性能

图28

29、将一些ActiveRecord实现重构为Redis原生命令实现,在整个足球比赛期间,在阿里云监控中,Redis的CPU使用率最高为21.1%,因此响应时间正常,如图29

将一些ActiveRecord实现重构为Redis原生命令实现,在整个足球比赛期间,在阿里云监控中,Redis的CPU使用率最高为21.1%,因此响应时间正常

图29

30、总结:Yii 2 的 ActiveRecord,相关方法对于Redis的CPU计算压力排行:insert() < one()/exists() < count()/all(),当某个Redis模型的key的数量超出10000后,如果要执行查询(有where条件)操作,建议不要使用ActiveRecord,如图30

总结:Yii 2 的 ActiveRecord,相关方法对于Redis的CPU计算压力排行:insert() < one()/exists() < count()/all(),当某个Redis模型的key的数量超出10000后,如果要执行查询(有where条件)操作,建议不要使用ActiveRecord

图30

原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/250376.html

(0)
上一篇 2022年4月29日
下一篇 2022年4月29日

相关推荐

发表回复

登录后才能评论