压力测试与性能分析方法论PerformancetestingBasicperformancetestingCommonclassificationPerformancetesting.用于验证系统性能是否达到设计预期。一般来说，对系统的压力会比较小，不会压垮系统。这只是一个简单的验证负载测试。通过不断施加负载压力，寻求系统的最佳处理能力和最佳性能状态，以达到最大的性能指标。一般来说，负载测试的结果比性能测试的结果高一点。稳定性测试。可以认为是负载测试的一个子集，长时间不均匀地加压，然后检查系统各项指标是否正常。压力测试：对我们来说很常见。通常，我们将此称为压力测试，用于确定系统可以承受的最大容量。压力测试一般是压到系统能够承受的最大点，然后得出一个峰值结论。压测类型和压测方式压测类型一般分为单业务压测和全链路压测两种。而我们常见的压力模式有以下两种：并发模式（从用户的角度来模拟用户模式）并发指的是并发用户数，从业务角度来模拟同时在线的用户数同时，为了达到预期的并发量，计算吞吐量，需要进行转换。但在某些场景下，更符合场景预期的RPS模式（吞吐量模式是从请求吞吐量的角度模拟的）。RPS（RequestsPerSecond）是指每秒的请求数。RPS模式是“吞吐量模式”。通过设置每秒发送的请求数，从服务器的角度，可以直接衡量系统的吞吐能力，省去了从并发到RPS的繁琐转换，一步到位。并发模式和RPS模式没有优缺点，各有各的适用场景。常用压测工具常用压测工具如下：wrk:https://github.com/wg/wrkab:https://httpd.apache.org/docs/2.4/programs/ab.htmlwebbench性能指标常用性能指标业务指标：并发数、吞吐量、响应时间并发数。指系统同时处理的请求数。对于Internet系统，一般指同时访问系统的用户数。吞吐量（QPS最大值）：指单位时间内系统处理的请求数，反映系统的处理能力。我们一般用TPS、QPS等指标来衡量。吞吐量也可以分为平均吞吐量、峰值吞吐量和最小吞吐量。响应时间：交易的处理时间。通常是指从发出请求，到服务器处理完返回，再到收到响应数据的时间间隔。一般有平均响应时间、P95、P99。响应时间和吞吐量必须达到一个平衡点。随着吞吐量的增加，响应时间会先维持在某个点，然后开始快速增加，随后吞吐量就很难增加了。我们对响应时间有要求，所以我们不能只追求吞吐量，我们必须在合理的响应时间内找到最大的吞吐量。响应时间必须基于成功率。如果出现故障，则响应时间无效。成功率一般为100%。它们之间的关系是：QPS（TPS）=并发数/平均响应时间吞吐量理论值=并发数/平均响应时间并发数=QPS*平均响应时间系统资源：CPU闲置率、内存占用率、网络IO、性能计数器比如磁盘读写量，句柄数等，是指服务器或操作系统性能的一些指标数据，包括系统负载SystemLoad，对象数和线程数，内存使用率，CPU使用率，磁盘和网络I/O使用情况等指标。这些指标是系统监控的重要参数，反映了系统负载和处理能力的一些关键指标，通常这些指标与性能有很强的相关性。这些指标很高，成为瓶颈，通常表明可能存在性能问题。最好的方法是用百分比来指代平均值。这是不可靠的。最正确的统计方法是使用百分比分布统计。最佳做法是使用百分比。例如TopPercentile（TP）指标，TP50表示50%的请求小于某个值，TP90表示90%的请求小于某个时间。不管是哪种类型的压测，压测要观察的指标一般包括：成功率、失败率、系统资源（CPU、内存、带宽、IO）响应时间、平均响应时间、P95/P99响应时间、一定要注意P95和P99，不仅仅是平均时间，P99时间更能判断在线用户的时间体验吞吐量（QPS/TPS）。基本压测数据示例如下：生成严谨的压测报告我们在分析系统性能问题的时候，需要找到关键点。这就要求我们的压力测试报告要真正有效、非常严谨、清晰。一定要一步步分析瓶颈，一定要明白为什么到了瓶颈，然后怎么去优化。？因此，我们需要输出严格的压力测试报告。有几点体会：压测时，要找到性能拐点；如果压力一上来就遇到瓶颈，就需要往回走一点，直到找到最好的性能拐点。系统性能呈抛物线形。达到性能峰值后继续施加压力会导致性能下降。所以我们压测最重要的是找到最好的性能拐点。所以在整个施压过程中都是逐渐加压，达到性能峰值后再继续加压。如果继续加压后性能不增反减，说明拐点已经到了。如何分析性能瓶颈，找到QPS无法提升的原因？QPS不会一直到某个点之后就持平甚至下降，会出现一个性能拐点。这时候就要开始分析原因了。具体做法是，先抓取没有达到限制的profile情况（cpu、block、io、memory），然后抓取刚刚达到限制的，最后抓取已经超过限制的，然后分析这些情况是哪些系统资源，或者是外部接口导致了性能问题。如果某个组件或外部服务是性能瓶颈点，则需要进一步分析。组件使用姿势不对？它不处理连接数吗？不能说找到某个部件就问题就解决了，还需要进一步深入的检查。知道单机和集群能承载的性能，单机在拐点的最大QPS是多少？平行扩容后QPS是多少？是线性增长吗？（肯定不会线性增长，到一定程度之后，相关资源就会出现瓶颈，关键是找到对应的瓶颈。）如何分析系统资源，比如CPU，比如先看CPU。如果CPU没有跑满，就说明不是CPU的问题，所以不用关心CPU，接下来需要其他资源，比如io、swap、内存、网卡等。如果有多个CPU核心，那么观察每个核心cpu的使用情况，不能只看整体的CPU使用情况。如果CPU已满，则抓取CPU的profile，观察哪个调用更耗时。系统上线前做好容量预估。必须能够粗略的预测Estimate/evaluate，然后通过压测验证了解每一个细节，包括资源、依赖、部署、机房分布、降级策略、容灾方案、备份方案等。容量预估是大型系统上线的必经之路，因为只有对容量进行合理的预估，才能更好的根据所承载系统的规模来设计我们的系统。容量规划需要能够用最少的机器抵抗更多的流量；规划ok之后，我们需要使用一些性能压测的手段来验证是否符合预期。有了合理的容量规划和评估后，我们只有在上线前去压测系统时，才能知道自己需要加压到什么程度。那么，容量估算不仅仅是头脑风暴。能力评估需要考虑以下几点：1.获取业务Indicators，评估查询产品、运营的总访问量，获取一些uv、pv等指标2.评估每天平均访问??QPS86400秒，一般认为该请求发生在白天，即4w秒。总量除以总时间，算出每天4w秒；3.评估峰值QPS系统容量规划时，不能只考虑平均QPS，而要考虑能抗峰值的QPS。根据业务曲线，一般峰值QPS是平均QPS的3-3的4倍4.评估整个业务系统下各模块和子系统的相关指标5.评估系统和单机限制QPS，评估需要多少台机器做压测和数据分析6.适当的冗余，压测得到的结果，其实上线后我们需要做一些冗余，避免线上的实际压力将无法快速扩展。做好分析总结。比如：这个系统上线后，真的能扛得住吗？除了压测数据，还要有自己的预估。在自己的系统中，哪些方面可能存在瓶颈，哪些方面上线后会出现问题？系统上线前必须有充分的准备和整体评估/预估。系统上线后，无法处理怎么办？有限流方案吗？有降级选项吗？10万用户的系统现状如何？那么如果100万用户的情况，是线性增长吗？需要考虑什么？系统上线前，需要能够有预估/评估，然后通过压测验证，了解每一个细节，包括资源、依赖、部署、机房分布、降级策略、容灾方案、备份计划和一些具体案例压力测试方法测试数据准备高质量的测试数据应该能够真实反映用户的使用场景。我们一般选择在线真实数据作为数据源，经过采样、过滤、脱敏后，作为性能测试的测试数据。但是在用真实数据进行测试之前，必须先离线模拟测试数据，至少要验证整个系统的基本性能需求，然后才能使用真实数据进行性能测试。存储层（数据库和缓存）的压测方式如果针对无状态服务，很容易提升并发能力，不思量就可以扩容。但是对于一个有状态的存储系统来说，它所能支持的最大并发数并不是无限可扩展的，所以我们必须能够了解我们的数据存储层能够承受多少，对于这种存储集群的压力测试一般是：首先，在单机上进行压力测试，然后分析集群的整体容量。需要注意的是，集群所能承载的容量并不是单机的累加值。一般集群每增加一台机器，可以减少80%。粗略的评估。最后需要说明的是，集群的整体弹性需要根据实际情况实现合理配置，并不是集群中的机器越多越好。按下一个符合预期的值。本文转载自微信公众号《后端系统与架构》，作者“AllenWu”，可通过以下二维码关注。转载本文请联系“后端系统与架构”公众号。
