简介
背景
兄弟部门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个话题了