目录

前言

需求评估分析

性能测试方案

---

前言

前几天还在北京出差时候，微信群有个同学问了一个问题，为什么800并发压测，服务器还没有报错？当时群里其他同学提了很多观点，比如：

• 并发不够，加并发！
• 要不要考虑首页进来多少人？
• 是不是有限流，流量都被拦截了？
• 我看CPU都打满了，压测要关注硬件指标！
• 是不是你压测机配置比较低，无法发起这么多并发？
• ............

林林总总感觉说了很多，又感觉都没说到位。正好周四时候，从同事那里听到一个性能需求，说来也蛮有意思的，需求大致是这样：

网关要验证在跨可用区情况下，支撑20W的TPS。就这一句话，我当时有点诧异（因为以我对我们公司目前业务及技术架构的理解，根本不需要20W的TPS）。

那么，问题来了：如果是你，听到这样的“一句话需求”，你会如何评估分析，然后制定压测方案呢？

这篇文章，聊聊我对这个需求的一些理解和分析，以及我会如何设计性能测试方案。

需求评估分析

先来聊聊如何分析这个性能需求，关于性能需求分析，我总结下面几点roadmap：

接下来，按照上述思维导图，我会通过几个不同问题的解答，来描述我的分析思路。

谁提的需求，目的是什么？

流量网关的研发同学提了一个性能测试需求：网关要验证在跨可用区情况下，支撑20W的TPS。

做个关键字提取：流量网关、跨可用区、20W的TPS。

什么是流量网关？

简单来说，流量网关就是所有请求的流量入口，承载了所有用户请求。如下图所示：

如何理解跨可用区？

一般来说，云服务的可用区，可以理解为同一个机房的不同虚拟机集群。

为了避免某个可用区由于网络硬盘等原因损坏导致服务不可用，跨可用区的服务部署是一种常见的容灾手段。

流量网关有什么特点？

负载均衡：跨多个服务的动态负载均衡；

身份验证：即用户的身份鉴权，登录态、黑白名单等；

限流限速：基于速率、请求数、并发等维度进行流控；

其他特点：加解密、A/B测试、灰度发布、监控告警、服务治理等功能；

压测流量网关有什么难点？

网关是用户请求流量的入口，因此访问压力会很大，即我们常说的QPS很高。那么在压测时，要考虑下面几点：

• 需要能支撑发起很多并发请求的工具；
• 网关服务的应用需要部署集群，来应对高并发；
• 由于只是跨可用区，一般云服务可控制在0.5ms以内；

在什么场景下为谁提供服务？

上面介绍了流量网关的特点，这里的场景指的是业务场景或者说测试场景，即：验证网关的哪些功能场景下的性能表现。上述的网关特点中，一般需要压测验证的场景有鉴权、加解密、身份验证。

目前系统架构调用关系是怎样的？

做性能测试，最怕的是不了解系统架构就开始无脑高并发！

了解系统架构及服务间的调用关系，才能设计合理的压测场景，准备对应的脚本和数据。

如何搭建满足需求的性能测试环境？

根据上面的分析，跨可用区的网关应用集群，在搭建环境时，需要考虑的有下述几点：

• 集群均匀分布在不同可用区；
• 网关应用的单机配置（比如8C16G）；
• 虚拟机型保持一致（内核版本、计算型/IO型）；
• 需要绑定专门的域名，SLB和带宽需要大于预期的指标；
• 压测工具需要尽可能的支撑更高的并发流量发起（比如Wrk）；
• 因为涉及到鉴权和身份验证，需要提前预热相关的auth、token数据到缓存；

如何评估性能需求的技术指标是否合理？

上面提到了性能指标是20W的TPS，那这个指标是否合理呢？

首先，性能需求的技术指标是否合理，要结合实际的业务场景和目前峰值流量及未来增长趋势来综合评估。

假设流量网关被所有业务接入，业务对RT比较敏感，业务请求RT的目标是10ms；目前的线上峰值QPS是5W-QPS，预计未来半年增长到10W的QPS。

那这个时候，如何评估技术指标，或者说设定合理的技术指标呢？我们可以结合实际情况讨论，得到下面这样的一个技术指标：

• ART&99RT：≤2ms；
• 安全水位下的QPS：≥10W；
• TPS：统计核心业务的核心链路当前吞吐能力，做聚合计算，保持一定上浮；

当然，上述的指标有个前提：业务不接受有损。

如果业务接受有损，那么性能的技术指标无须这么苛刻（因为可以限流降级）；

性能测试方案

说到了性能测试方案，我偶然翻出了19年6月份画的一个性能测试流程职责说明表，见下图：

聊到这里，该如何设计性能测试方案呢？答案已经在上述的需求分析里了。

加油吧，测试人！如果你需要提升规划，那就行动吧，在路上总比在起点观望的要好。未来的你肯定会感谢现在拼命的自己！