聊聊性能基准测试和容量评估规划

星球有同学问了一个关于性能测试的问题，我觉得蛮有意思的，遂分享给大家，顺带聊聊我的分析思路和实践经验。

问题背景是这样：一个 1.0 版本的新系统还未上线，需要对其进行性能测试(性能基准)，该如何开展工作？其中流量模型如何评估？涉及到缓存的场景如何压测？压测场景的流量配比该如何配置？线上的容量评估规划又该如何进行？

1、流量模型

未上线的系统因为没有真实的用户业务数据，因此无法得到较为准确的流量模型。但如果没有流量模型，则压测得到的系统性能指标又不具备太大的参考价值，因此流量模型还是需要进行评估的，如何评估呢？

首先看系统的上线计划，比如上线后是全量推送还是灰度。

如果是全量推送，则可以参考公司其他业务的总用户数量，按照已上线系统的流量变化趋势，得到一个粗略的数值。然后按照该系统的业务类型以及产品方预估的业务高峰期，按照二八原则进一步得到峰值的 QPS 数值。最后则是按照该系统的业务链路和调用关系，得到流量模型。

如果是灰度，则按照灰度的策略优先评估出第一次灰度的流量。比如注册用户 100W，先灰度 10%，观察一周没问题后灰度到 20%。这种情况下流量模型的起始值按照 10W 来计算，然后按照业务调用关系逐次转化计算。

PS：关于流量模型具体的评估方式和案例，请看文末的推荐阅读。

2、缓存场景

压测涉及到缓存是很常见的场景，这个问题的解决方法也很简单。

通过小流量压测或批处理的方式，将需要缓存的数据预热到缓存中。这一步的性能表现不作为真实的性能结果记录，主要目的是该缓存的数据进入缓存，保证测试场景的真实性。

有同学担心如果先预热再压测，这样后期的性能测试结果会和系统上线后用户访问的表现差异加大，这点其实无需担心。新系统上线前，本身就需要对基础数据和缓存数据进行铺底和预热，这也是快速提高系统性能以及用户体验的方法。

3、场景流量配比

先解释一下流量配比。举个例子：订单业务对应的业务应用是 order-interface，和订单有关的功能模块都集成在该应用中，比如订单列表、订单详情、创建订单、订单支付。

从服务层级来说，请求从网关路由到 order-interface 服务的 QPS 是固定数值，但不同的功能模块(接口)在同一时间段内的 QPS 是不同的，且其性能表现也会有所差异。为了得到应用服务层级的性能表现，则势必要对其进行混合场景压测。

这里订单服务 order-interface 中不同功能模块对应的接口 QPS 比例，就是所谓的流量配比。

再聊聊这种场景下的流量配比策略，其实思路很简单：拿到兜底结果即可。

不同的流量配比下，系统的性能表现是不同的，可以按照不同的流量比例组合，多验证几组得到不同的性能结果。

因为系统还未上线，因此需要在上线时为系统留出一定的冗余空间。将上述方法得到的性能测试结果，其中最差的一组作为基准，只要该组性能测试数据满足预期即可。

等系统上线后，再根据实际的业务和技术监控数据，得到新的流量模型和流量配比，快速调整优化并压测验证。

4、容量评估规划

很多测试同学对容量评估规划的理解有一定误区，实际上容量评估和容量规划，是两件事。

在实际的性能测试场景中，容量评估规划的步骤是：容量评估-压测验证-线上监控-调整优化。其中最后一步，才是所谓的线上容量规划。

所谓容量评估，就是 ABCD 不同业务以及对应的应用和中间件(Redis/MQ)的大致数值。

通过线下性能测试环境进行单机或小集群性能验证，得到一个粗略的结果，用最差一组的性能结果作为上线基准。

再者新系统上线，也是通过资源冗余来做稳定性保障的。等系统上线后，用新得到的流量模型和流量配比，快速调整优化并压测验证，再进一步调整各业务应用的水位以及对应的资源配置。这样才算是完成了容量规划。

容量规划是一个持续性渐进的过程，而非一锤子买卖。