迎难而上,QPS提高22+倍

简介

记录1次性能提升的经历,它最大的挑战不在于性能提升,而在于时间急,涉及的面广(比如:机房F5的SSL/TLS性能,机房互联网流量费和项目投入产出比等)。性能指标:至少支持10K QPS,10ms内服务应答,2+%的超时会被[流量方](BATJ中的一家)打低业务流量,10+%的超时封号。

背景

因EA整体的架构规划,部门A的试错尝鲜类需求被划分给部门B来实现。这是1个互联网引流的需求:[流量方]会将客户移动端的加密设备信息调用我司接口,我司需告知[流量方]这个设备是否需要看我司的广告。9.20号部门B和[流量方]做了2次性能压测,没通过:1200 QPS,60+%超时率;800 QPS,17+% 超时率。本计划9.22号上线,兼着部门A架构的我被安排进入项目。经多轮沟通分析,因该需求涉及的面比较广,需向多位部门长、CTO汇报请示,同时要向集团IT报备,再加之8天的国庆假期,最后于10.13上线该需求。

兄弟部门B的失误在于过于乐观、简单地看待了这个业务需求。通过了解生产环境现状、多轮和[流量方]&集团IT沟通后,摸清了大体的情况

现状分析

开始分析代码,以及整个链路的运行环境

解决方案

通过修改代码、变更Web容器提升单机性能,为后续横向scaling做好基础

性能压测

下图描述的主要是测试环境压测的情况。可以看出,测试环境的压测数据单机性能已经达到16+K 的QPS,但担心[流量方]的统计指标(主要是并发数)有出入,因此预估生产环境集群可以正常抗10K的QPS。在10.16日和[流量方]进行生产压测后,发现集群可以抗30K的QPS(这也是下图【3倍生产环境[流量方]实压转换比】的参考来源)。其实还可以再往上压,35K时[流量方]反馈响应耗时出现了波动,但互联网的宽带有限制,也担心机房F5的问题,同时已超额满足业务预期,就停止了生产的压测

总结

部门B确实做过一些压测,但测试目标不明确(众多的性能指标中,应该以该需求最核心的Web服务器响应耗时这个指标作为基线,来测试单台机器支持的最大QPS),测试工具不准确(当时用部门B的压测方法模拟1000 QPS,我查了下其实只有48的QPS),这也导致了上线前最后1关也就轻易的过了

另外,我也过于轻信了运维和安全同事他们对Openresty的压测指标(可支持80+w的QPS),测试环境压测时没有测Openresty的性能。不过还好,安全的同事心虚了,在和[流量方]生产压测前,当天下午生产环境压测了一下Openresty的性能,紧急去掉了Openresty节点。当时Openresty压测数据表明:在保证吞吐量的前提下,响应耗时只能是标准需求的接口延迟在200ms左右。关于Openresty的性能调优,或者是不是Openresty中的Lua脚本有性能问题(理论上编译型的Java会比解释型的Lua快),这又是另1个话题了

posted @ 2020-10-18 22:51  JacobusLi李依洁  阅读(1260)  评论(3编辑  收藏