在性能测试中，需要根据具体的性能需求和系统架构等情况，采用不同的测试策略，其中最常见的策略就有容量测试。
什么是容量 如何理解
容量定义
所谓容量，即系统处于最大负载状态或某项指标达到所能接受的最大阈值下对请求的最大处理能力。
如何理解
- 系统的容量（处理能力）是有限的；
- 容量是可度量的；
如何统计容量指标
统计维度
- 最大负载状态 服务器CPU使用率达到100%
- 内存使用达到最大值
- 磁盘IO延时超过所能接受的最大时延
- 磁盘使用率超过最大限制
- 网络使用率达到上限（最大吞吐量）
- 最大接受阈值 每秒请求数/事务数（QPS/TPS）
- 响应时间（ART/99%RT）
- 事务成功率（一般要求99.99%甚至更高）
- 超时/异常错误率
- 配置参数，比如：最大连接数、最大线程数、JVM内存分配上限
统计方法
- 埋点采集：即在系统的各个节点，根据需要添加埋点，针对性的进行数据采集。
- 日志/数据库：通过日志服务（比如ELK）或者运维监控（现在很流行的Devops），采集分析数据。
- Agent/探针：在需要采集的节点添加Agent/探针，实时采集，数据存入时序数据库，实时展示。
注意事项
- 采集对比的数据一定要采集线上的真实数据，这样才能反映真实客观的系统压力。
- 如果是在测试环境，配置一定要和线上保持一致（服务器数量可以不同，但配置尽可能保持一致）
容量测试
容量测试是性能测试里的一种测试方法，它的目的就是测量系统的最大容量，为系统扩容，性能优化提供参考，节省成本投入，提高资源利用率。
测试思路
- 根据具体的业务情况和系统架构，通过配置测试的手段，测量得到单个服务节点在对应的业务场景下最大的性能表现。
- 根据系统架构（集群、分布式、微服务）特点，通过启用≥2的服务节点，来得到服务节点的增加和系统性能的提升比例。
- 通过线上采集的系统数据，分析出过去某段时间（或某个业务）的高峰流量，然后通过计算，得到容量扩容，需要投入的实际服务数量。
约束 or 停止条件
- 业务线相关人员必须到位，测试过程能促使我们更加理解业务形态，容易出现的问题可能就是未来的故障点。
- 在测试过程中，只要限定的某项指标达到最大可接受阈值或某项资源达到最大使用状态，即刻停止测试。
选择合适的容量指标
考虑到业务需求和系统架构的不同，在选取容量指标时一般遵循如下原则：
- 数据密集型：即并发请求量较大的类型，一般TPS和RT是比较关注的指标。
- 数据存储型：即需要存储读写的数据量较大的类型，一般吞吐量和IO是比较关注的指标。
容量规划
为什么需要容量规划
对于业务越来越复杂的商业形态，每个业务都由一系列不同的系统来提供服务，每个业务系统都部署在不同的机器上。容量规划的目的在于让每一个业务系统能够清晰地知道：
- 什么时候应该增加服务节点，什么时候应该减少服务节点（比如服务端接受到的流量达到什么量级）（比如压测，周年庆，大促等）
- 为了压测，周年庆，大促等业务需求，需要扩充到什么数量级的服务，才能即保证系统的可用性、稳定性，又能节约成本
容量规划四步走
- 业务流量预估阶段：通过分析历史数据以及实时的线上监控，预估未来某个时间点或者某个业务可能会有多少多少的流量冲击；
- 系统容量评估阶段：根据具体的业务场景，分析每个业务场景的流量配比，然后计算每个业务大概需要多少服务节点来提供可靠稳定的性能支撑；
- 系统容量测试阶段：通过全链路压测或者PAT/UAT环境的压测，来模拟真实的业务场景，确定每个服务节点的具体性能表现，进行针对性的调整；
- 流量分配调整阶段：根据压测的结果，设定限流、服务降级等系统保护措施，来预防当实际流量超过系统所能承受的最大流量时，系统无法提供服务；
扩容手段
垂直扩容
- 升级服务的硬件配置，让单个服务节点的容量更大，来提供更高的系统服务能力。比如：加大CPU数量和内存，更换性能更好的服务器，高性能SSD或者PCIE flash卡等。
- 如果用容器，可以启用VPA，启用更多的容器来满足业务增长需求，此场景下需要注意后端DB和缓存的连接数使用情况，并不是能无限扩展的。
水平扩展
- 即增加服务节点的数量，让可提供服务的服务变得更多，来提升系统总体的服务能力。常见的方式有：
- 服务集群：服务器的数量由1→N（但需要重点关注负载均衡）；
- 分布式：提供服务的节点由统一集中管理部署，分散到不同的地点；
- 容器：提供更灵活的弹性扩容机制，根据具体的访问流量大小来弹性扩容或者缩容；
容量评估的步骤与方法
预估总访问量
- 最简单的办法就是：询问业务方，询问运营同学，询问产品同学，看产品和运营对此次活动的流量预估。
- 不过，业务方对于流量的预估，应该就两个指标，pv 和 用户访问数。技术人员需要根据这两个数据，计算其他相关指标，比如 QPS 等。
预估平均QPS
-
总请求数 = 总PV * 页面衍生连接数
平均QPS = 总请求数 / 总时间
比如：活动落地页1小时内的总访问量是30w pv，该落地页的衍生连接数为30 ,那么落地页的平均QPS为 (30W30) /(6060) = 2500
预估峰值QPS
- 系统容量规划时，不能只考虑平均QPS，而是要峰值QPS，如何评估峰值QPS呢？
- 这个要根据实际的业务评估，也可以通过以往一些活动的 pv 等数据进行预估。
- 一般情况，峰值QPS大概是均值QPS的3-5倍，日均QPS为1000，于是评估出峰值QPS为5000。(举例，根据实际情况和经验来判断)
预估系统、单机极限QPS
- 这个性能指标，是服务器，最基本的指标之一，所以没有其他的办法，就是压力测试。通过压力测试，算出服务器的单机极限QPS 。
写在最后
- 需要注意的是，以上都是计算单个服务器或是单个集群的容量，实际生产环境是由web, 消息队列，缓存，数据库 等等一系列组成的复杂集群。
- 在分布式系统中，任何环节出现瓶颈，都有可能导致雪崩效应，最后整个集群垮掉 。
- 要了解规划整个平台的容量，就必须计算出每一个节点的容量，找出任何可能出现的瓶颈所在。
- 墨菲定律一定会发生，只是时间问题。
