简介

记录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个话题了