aso搜索排名优化,seo软件优化工具软件,提供设计的的网站,丹东市网站开发公司背景
项目中使用AWS的SQS消息队列进行异步处理#xff0c;QA通过压测发现单机TPS在23左右#xff0c;目标性能在500TPS#xff0c;所以需要对消费逻辑进行优化#xff0c;提升消费速度。
目标
消费TPS从23提升到500
优化流程
优化的思路是先分析定位性能瓶颈#xff…背景
项目中使用AWS的SQS消息队列进行异步处理QA通过压测发现单机TPS在23左右目标性能在500TPS所以需要对消费逻辑进行优化提升消费速度。
目标
消费TPS从23提升到500
优化流程
优化的思路是先分析定位性能瓶颈再针瓶颈进行优化。
性能定位
要定位性能先要准确评估每秒处理的消费数量以及处理每个消息过程中每一步操作的耗时发现耗时大头在哪里。
准确评估消费速度TPS
消费消息的入口是AwsConsumer#doUpdateCoin所以可以通过Arthas的monitor命令监控方法的执行TPS和RT。 monitor -c 1 AwsConsumer doUpdateCoin -n 1000
这个命令会统计doUpdateCoin的调用信息每1秒打印一次结果总共打印1000次。通过它能定量分析消费的TPS命令会返回以下信息。 监控项 说明 timestamp时间戳classJava 类method方法构造方法、普通方法total调用次数success成功次数fail失败次数rt平均 RTfail-rate失败率
这是一次调用的结果 可以看到方法每秒执行26次平均执行时间是179.44秒。从这里我们能得出两个结论
TPS是26的确不高AVT-RT在179.44ms那么一个线程TPS约等于5。
因为RT比较高猜测在RT上还有优化的空间下面从每条消息消费的过程继续看是否存在瓶颈。
查看每次处理的明细
要看每次请求的信息可以通过tt命令它会采集方法每次执行的耗时、成功还是失败。 tt -t AwsConsumer doUpdateCoin -n 1000 表格字段 字段解释 INDEX时间片段记录编号每一个编号代表着一次调用后续 tt 还有很多命令都是基于此编号指定记录操作非常重要。TIMESTAMP方法执行的本机时间记录了这个时间片段所发生的本机时间COST(ms)方法执行的耗时IS-RET方法是否以正常返回的形式结束IS-EXP方法是否以抛异常的形式结束OBJECT执行对象的hashCode()注意曾经有人误认为是对象在 JVM 中的内存地址但很遗憾他不是。但他能帮助你简单的标记当前执行方法的类实体CLASS执行的类名METHOD执行的方法名
这是一次调用的结果 从这里可以看出消息处理耗时有的大有的小说明处理性能不稳定。需要再深入看RT较大的消息耗时在哪里。
处理一条消息的内部耗时
要看单次处理过程中每个步骤的耗时一般我们会通过在代码前后记录时间再用日志打印出来。例如long s System.currentTimeMillis();
这种方式效率很低需要不断加日志并重新部署服务。Arthas有一个trace命令可以查看方法的调用栈信息包括调用的方法和方法执行的耗时。 trace AwsConsumer doUpdateCoin #cost 100 -n 1
这是一次调用的结果 这个命令会打印doUpdateCoin耗时大于100ms的请求调用栈信息可以看到doUpdateCoin方法执行了323ms其中99.62%的耗时集中在PlayerService:loadByOpenId()方法调用。然后我们就会想看一下loadByOpenId方法到底什么地方耗时。
trace命令不能直接指定调用栈的层级可以通过动态trace的方式再创建一个listener去监听loadByOpenId方法这样会把第二个listener的结果打印在前面的trace结果上。 trace PlayerService loadByOpenId --listenerId 9 可以看到在原来的结果上多了loadByOpenId方法调用的明细。也发现了loadByOpenId方法耗时集中在load方法上这是ORM框架提供的方法直接去查询数据库。所以基本可以断定本次处理慢是由于这个查询引起的。后面就是看查询条件是没有命中索引导致了慢还是数据库本身性能存在问题。
总结
因为本次压测是在测试数据库所以数据库本身不稳定虽然定位到了这个性能瓶颈对消费逻辑优化帮助不大需要更精准的评估线上数据库的性能。但是通过monitor命令长时间观察doUpdateCoin方法的执行情况发现大部分时间平均RT其实是比较低的所以不应该是单次请求慢而降低了总体的消费TPS。可能是因为SQS消息拉取阶段存在瓶颈所以尝试加大了消费的线程数、将单条拉取改成批量拉取。重新压测后消费TPS从23提升到了342。
