在性能测试中，需要根据具体的性能需求和系统架构等情况，采⽤不同的测试策略，其中最常见的策略就有容量测试。
这篇博客，就来聊聊容量测试以及容量规划的⼀些内容。。。
⼀、什么是容量？如何理解？
在开始之前，有⼀点需要知道：系统的处理能⼒是有限的！
1、容量定义
所谓容量，即系统处于最⼤负载状态或某项指标达到所能接受的最⼤阈值下对请求的最⼤处理能⼒。
2、如何理解
①、系统的容量（处理能⼒）是有限的；
②、容量是可度量的；
⼆、如何统计容量指标？
1、统计维度
⼀般来说，可以从如下两个维度来定量系统的容量：
维度类型 列举说明
内存使⽤达到最⼤值
磁盘IO延时超过所能接受的最⼤时延
磁盘使⽤率超过最⼤限制
⽹络使⽤率达到上限（最⼤吞吐量）
最⼤接受阈值 每秒请求数/事务数（QPS/TPS）
响应时间（ART/99%RT）
事务成功率（⼀般要求99.99%甚⾄更⾼）
超时/异常错误率
配置参数，⽐如：最⼤连接数、最⼤线程数、JVM内存分配上限
2、统计⽅法
⼀般来说，常⽤的采集数据的⽅法，有以下⼏种⽅式：
①、埋点采集：即在系统的各个节点，根据需要添加埋点，针对性的进⾏数据采集； ②、⽇志/数据库：通过⽇志服务（⽐如ELK）或者运维监控（现在很流⾏的Devops），采集分析数据；
③、Agent/探针：在需要采集的节点添加Agent/探针，实时采集，数据存⼊时序数据库（⽐如influxdb），实时展⽰；
3、注意事项
①、采集对⽐的数据⼀定要采集线上的真实数据，这样才能反映真实客观的系统压⼒。
②、容量测试环境的配置，⼀定要和线上保持⼀致（服务器数量可以不同，但配置尽可能保持⼀致）。
三、容量测试
容量测试是性能测试⾥的⼀种测试⽅法，它的⽬的就是测量系统的最⼤容量，为系统扩容，性能优化提供参考，节省成本投⼊，提⾼资源利⽤率。
1、测试思路
①、根据具体的业务情况和系统架构，通过配置测试的⼿段，测量得到单个服务节点在对应的业务场景下最⼤的性能表现； ②、根据系统架构（集、分布式、微服务）特点，通过启⽤≥2的服务节点，来得到服务节点的增加和系统性能的提升⽐例；
③、通过线上采集的系统数据，分析出过去某段时间（或某个业务）的⾼峰流量，然后通过计算，得到容量扩容，需要投⼊的实际服务数量；
2、约束/停⽌条件
在测试过程中，只要限定的某项指标达到最⼤可接受阈值或某项资源达到最⼤使⽤状态，即刻停⽌测试。
3、选择合适的容量指标
考虑到业务需求和系统架构的不同，在选取容量指标时⼀般遵循如下原则：
①、数据密集型：即并发请求量较⼤的类型，⼀般TPS和RT是⽐较关注的指标；
②、数据存储型：即需要存储读写的数据量较⼤的类型，⼀般吞吐量和IO是⽐较关注的指标；
四、容量规划
1、为什么需要容量规划？
对于业务越来越复杂的商业形态，每个业务都由⼀系列不同的系统来提供服务，每个业务系统都部署在不同的机器上。容量规划的⽬的在于让每⼀个业务系统能够清晰地知道：
①、什么时候应该增加服务节点，什么时候应该减少服务节点（⽐如服务端接受到的流量达到什么量级）？（⽐如双⼗⼀，⼤促，秒杀）
②、为了双 11 、促销、秒杀、渠道拓展引流等业务需求，需要扩充到什么数量级的服务，才能即保证系统的可⽤性、稳定性，⼜能节约成本？
2、容量规划四步⾛
①、业务流量预估阶段：通过分析历史数据以及实时的线上监控，预估未来某个时间点或者某个业务可能会有多少多少的流量冲击；
②、系统容量评估阶段：根据具体的业务场景，分析每个业务场景的流量配⽐，然后计算每个业务⼤概需要多少服务节点来提供可靠稳定的性能⽀撑；
③、系统容量测试阶段：通过全链路压测或者PAT/UAT环境的压测，来模拟真实的业务场景，确定每个服务节点的具体性能表现，进⾏针对性的调整；
④、流量分配调整阶段：根据压测的结果，设定限流、服务降级等系统保护措施，来预防当实际流量超过系统所能承受的最⼤流量时，系统⽆法提供服务；
3、扩容⼿段
①、垂直扩容
升级服务的硬件配置，让单个服务节点的容量更⼤，来提供更⾼的系统服务能⼒。⽐如：
加⼤服务机器的CPU数量和内存，更换性能更好的⾼速缓存服务器，数据存储⽤NAS盘替换等。
②、⽔平扩展
即增加服务节点的数量，让可提供服务的服务变得更多，来提升系统总体的服务能⼒。常见的⽅式有：
服务集：服务器的数量由1→N（但需要重点关注负载均衡）；
分布式：提供服务的节点由统⼀集中管理部署，分散到不同的地点；
容器：提供更灵活的弹性扩容机制，根据具体的访问流量⼤⼩来弹性扩容或者缩容；
4、更多参考
关于容量规划，可以看这⾥：阿⾥巴巴全链路压测
关于集和分布式，看这⾥：分布式与集的区别是什么？
系统容量预估的问题，容量预估是架构师必备的技能之⼀。所谓，容量预估其实说⽩了就是，系统在down掉之前，所能承受的最⼤流量。这个事技术⼈员对于系统性能了解的重要指标。常见的容量评估包括流量、并发量、带宽、CPU，内存 ，磁盘等⼀系列内容。今天就来聊⼀聊容量预估的问题。
⼀，⼏个重要参数
QPS：每秒钟处理的请求数
并发量：系统同时处理的请求数
响应时间：⼀般取平均响应时间
很多⼈经常会把并发数和QPS 混淆，理解了上⾯三个要素的意义之后，就能推算出它们之间的关系：QPS = 并发量 / 平均响应时间
⼆，容量评估的步骤与⽅法
1：预估总访问量
如何知道总访问量？对于⼀个运营活动的访问量评估，或者⼀个系统上线后PV的评估，有什么好的⽅法？
最简单的办法就是：询问业务⽅，询问运营同学，询问产品同学，看产品和运营对此次活动的流量预估。
不过，业务⽅对于流量的预估，应该就两个指标，pv 和 ⽤户访问数。技术⼈员 需要更具这两个数据，计算其他相关指标，⽐如QPS 等。具体如何计算可参照我前⾯⼀篇 pv和并发 的⽂章。
2：预估平均QPS
总请求数 = 总PV * 页⾯衍⽣连接数
平均QPS = 总请求数 / 总时间
⽐如：活动落地页1⼩时内的总访问量是30w pv，该落地页的衍⽣连接数为30 ，那么落地页的平均QPS
(30w 30) /(60 60) = 2500，
3：预估峰值QPS
系统容量规划时，不能只考虑平均QPS，⽽是要抗住⾼峰的QPS，如何评估峰值QPS呢？
这个要根据实际的业务评估，通过以往的⼀些营销活动的 pv 等数据进⾏预估。⼀般情况，峰值QPS⼤概是均值QPS的3-5倍，⽇均QPS为1000，于是评估出峰值QPS为5000。
不过，有⼀些业务例如“秒杀业务”⽐较难评估业务访问量，这类业务的容量评估不在此讨论。
4：预估系统、单机极限QPS
如何预估⼀个业务，⼀个服务器单机的极限QPS呢？
这个性能指标，是服务器，最基本的指标之⼀，所以没有其他的办法，就是压⼒测试。通过压⼒测试，算出服务器的单机极限QPS 。
在⼀个业务上线前，⼀般都需要进⾏压⼒测试（很多创业型公司，业务迭代很快的系统可能没有这⼀步，那就悲剧了），以APP 推送 某营销活动为例（预计 ⽇均QPS 1000，峰值QPS 5000），业务场景可能是这样的：
1）通过 APP 推送⼀个活动消息
2）运营活动H5落地页是⼀个web站点
3）H5落地页由缓存cache、数据库db中的数据拼装⽽成
通过压⼒测试发现，web 服务器 单机只能抗住1200的QPS，cache和数据库db 能抗住并发压⼒，
（⼀般来说，1%的流量到数据库，数据库120 QPS还是能轻松抗住的，cache的话QPS能抗住，需要评估cache的带宽，这⾥假设cache不是瓶颈），这样，我们就得到了web单机极限的QPS是1200。⼀般来说，⽣产系统不会跑满到极限的，这样容易影响服务器的寿命和性能，单机线上允许跑到QPS 1200 * 0.8 = 960 。
扩展说⼀句，通过压⼒测试，已经知道web层是瓶颈，则可针对web 相关的做⼀些调整优化，以提⾼web 服务器 的单机QPS 。
还有，压⼒测试⼯作中，⼀般是以具体业务的⾓度进⾏压⼒测试，关⼼的是某个具体业务的并发量和QPS。
5：回答最开始那两个问题
需要的机器 = 峰值QPS / 单机极限 QPS
好了，上述已经得到了峰值QPS是5000，单机极限QPS是1000，线上部署了3台服务器：
（1）服务器能抗住么？ -> 峰值5000，单机1000，线上3台，扛不住
（2）如果扛不住，需要加多少台机器？ -> 需要额外2台，提前预留1台更好，给3台保险
三，最后
需要注意的是，以上都是计算单个服务器或是单个集的容量，实际⽣产环境是由web, 消息队列，缓存，数据库 等等⼀系列组成的复杂集。在分布式系统中，任何节点出现瓶颈，都有可能导致雪崩效应，最后整个集垮掉 （“雪崩效应”指的是系统中⼀个⼩问题会逐渐扩⼤，最后造成整个集宕机）。所以，要了解规划整个平台的容量，就必须计算出每⼀个节点的容量。出任何可能出现的瓶颈所在。
