性能测试全解

世界上没有陌生人，只有还没认识的朋友

一．性能测试的意义

由于软件系统的性能问题而引起严重后果的事件比比皆是，下面列举几个案例
(1)2007年10月，北京奥组委实行2008年奥运会门票预售，一时间订票官网访问量激致系统瘫痪，最终奥运会门票暂停销售5天。
(2)2009年11月22日，由于圣诞临近，eBay网站的商品交易量比去年同期增长33%，正式由于多出的这33%使得eBay网站不堪重负而崩溃，导致卖家蒙受当日销售额80%的损失，可谓损失惨重。
(3)12306订票网站自2010年上线以来就饱受诟病，每年春运期间，该网站总会因为抢票高峰到来而崩溃，用户在买票时出现无法登录的现象。2014年，12306网站甚至出现了安全问题，用户可以轻易获取陌生人的身份证号码、手机号码等信息。
上述事件都是由于软件系统没有经过性能测试或者性能测试不充分而引发的问题。无可厚非，软件功能的实现是软件核心，但行百里者半九十，软件性能也是软件质量的重中之重，开发或者测试，都应该关注质量问题

二．性能测试的分类，描述，术语解释

什么是性能测试：
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测，获取指标的过程

性能测试分类

1.基准测试：有基础的标准，这样能通过对比发现系统的不同点与变化。
应用于以下场景：
1）可以在制定的标准下通过基准测试建立一个性能基准，这样以后当系统的环境、参数发生变化之后，再进行一次相同标准下的测试，即可看出变化对性能的影响。
2）系统进行基准测试可以在较早的阶段发现性能问题。
3）某系统从来没有进行过任何性能测试，需要对该系统做一次性能评估作为后续开发调优的参考。
2.压力测试：测试系统在一定饱和状态下，例如cpu、内存等在饱和使用状态下，系统能够处理的会话能力，以及系统能否会出现错误；高压力下进行操作，看系统反应
3.负载测试：看能承受多大的负载，加压一直到崩溃；是在被测系统上不断增加压力，直到各项指标达到饱和，例如“响应时间”超过预定指标或者某种资源使用已经达到饱和状态。这种测试方法可以找到系统的处理极限，为系统调优提供数据。
4.并发测试是通过模拟用户的并发访问，测试多用户并发访问同一个应用，同一个模块或者数据记录时是否存在死锁
或者其他性能问题。
5.配置测试：配置测试方法是通过被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到各项资源的最优分配原则
例如在测试执行时更换、扩充硬件设备，调整网络环境、调整应用服务器和数据库服务器的参数设置，比较每次测试结果，从而确定各个因素对系统性能的影响。
6.可靠性测试：
可靠性测试是通过给系统加载一定的业务压力（例如资源在70%-90%的使用率）的情况下，让应用系统持续运行一段时间，测试系统在这种条件下是否能够稳定运行。
汇总：这些测试类型其实是密切相关，甚至无法区别，例如几乎所有的测试都有并发测试。在实际中不用纠结其具体的概念，而是要明确测试的目的。
1.性能验证：验证系统是否满足需求中的指标
2.性能测试：针对给定的系统，做全面的性能测试，得到系统的最大容量
3.性能测试 + 调优：针对给定的系统，做全面的性能测试，同时将系统调优到最优状态

性能测试基本术语

1.PV（Page View）用户访问页面的次数，此参数用来分析平均每秒有多少用户访问页面。
2.事务：从客户端发起一个或多个请求（这些请求组成一个完成的操作），到客户端接收到从服务器返回响应的过程。
3.TPS(Transaction Per Second）每秒系统能够处理的事务数。（事务数不一定等于请求数）
4.事务响应时间：系统处理一个事务所耗费的时间，如转账。
5.QPS（Query Per Second）：每秒处理的请求数
6.请求响应时间：从客户端发起一个请求开始，到客户端接收到从服务器返回的响应，整个过程所耗费的时间。
7.吞吐量：单位时间内系统处理的客户端请求的数量，包含一次性能测试过程中网络上传输的数据量的总和与硬盘传输数据流的速度，传输数据为读出数据和写入数据的和。
8.吞吐率：单位时间内网络上传输的数据量
9.点击率：每秒钟用户向服务器提交的请求数，这个指标是web应用程序特有的一个指标，可以想象为每秒中在页面上面进行多少次点击动作，但是需要注意的是鼠标单击的操作后，客户端有可能向服务去发送了多次请求。
10.资源使用率：对不同的系统资源的使用情况（CPU，内存，磁盘 I/O，GPU)

三．需要用到的工具

1.LoadRunner是一种业界领先的性能测试工具，由Hewlett Packard Enterprise开发。它支持多种协议和技术，包括Web应用程序、数据库、ERP系统、移动应用程序等，并提供可视化的测试脚本编辑器、测试场景设计工具和分析报告等功能。

2.Apache JMeter是一种Java框架，用于执行各种负载测试、性能测试和功能测试。它支持多种协议和技术，包括Web应用程序、数据库、FTP、SMTP、SOAP、REST等，可以帮助测试人员轻松地设计、执行和分析测试用例
3.Apifox 是一款集 API文档、API 调试、API Mock、自动化测试、性能测试于一体的协作工具
4.Gatling 是一种基于 Scala 语言开发的性能测试工具，可以用于 Web 应用程序和WebSocket 应用程序的负载测试和性能测试。它提供简单易用的 DSL 语言，可以帮助测试人员快速地编写测试用例，并提供实时统计数据和 HTML 报告等功能。

综上，一般使用Jmeter发起请求，压测监控使用 influxdb + grafana

四．执行步骤

1.需求分析

一定要仔细确认需求，不但体现你的专业，还能减少你的工作
1）新系统能力验证

比如，你们刚好开发了一个新系统，在上线前需要验证系统性能。这种情况比较简单；你可以有更多的自由选择测试环境、压力点和测试工具；测试策略上也比较灵活。并且如果性能测试结果没有明显的短板，也不需要进行调优。

2）客户有明确要求

这是一个好的结果，这说明客户对性能测试有一定的了解，知道他们需要的系统要达到一个什么样的标准。如：系统要求同时满足100用户登陆，平均每个用户登陆时间不能超过5秒。这个需求很明确，当然也不排除一些不懂装懂的用户，提一些不现实的要求。

不管怎么说，用户提要求了，这个比较容易，你可以对现系统做一次性能测试，至于，是通过优化系统还是增加硬件设备才能达到要求。就不是测试考虑的问题了。

3）找出系统性能瓶颈

这个需求的目的就很明确了，目的就是找出系统的性能瓶颈，进行调优或硬件扩容，所以性能测试的重点在系统的架构分析和业务分析上面。

4）稳定性验证（强度测试）

稳定性是系统的一个重要指标，因为系统一旦上线，就有可能会长期处在用户的访问状态，可能以前没发现的一些问题就会暴漏出来。比较典型的就是内存溢出，这种需求在测试策略上就要考虑性能测试的运行时长。

注意： 当拿到需求时一定要问测试的目的，一方面会显得你很专业；另一方面，我们通过测试目的可以知道后续性能测试工作的重点在哪儿？最主要的是，还可以揣摩出领导对这次测试的重视程度

2.计算并发量
1000000PV/day，根据八二原则，计算QPS/TPS,相信80%的流量会集中到20%时间内。24小时流量集中到白天8小时内，同时在午高峰达到高峰。

QPS : (1000000 * 80%) / (8 * 3600 *20%) = 138.9QPS
根据响应耗时公式预估所需并发，一次请求RT=100ms

则根据QPS = 并发数 / 平均响应时间，所以需要四舍五入需要14并发用户，一般用20线程
QPS：每秒钟处理完请求的次数；注意这⾥是处理完。具体是指发出请求到服务器处理完成功返回结果
TPS：每秒钟处理完的事务次数，⼀般TPS是对整个系统来讲的。⼀个应⽤系统1s能完成多少事务处理，⼀个事务在分布式处理中，可能会对应多个请求。
3.设计场景，编写脚本，执行测试
一般多次执行，观察TPS，响应时间等参数，看是否符合要求
4.调优
多次测试，进行调优，调优前后的 TPS、响应时间以及资源对比图，这才是体现测试和开发工程师最有价值的地方。
步骤一：确定问题
应用程序代码：在通常情况下，很多程序的性能问题都是写出来的，因此对于发现瓶颈的模块，应该首先检查一下代码。

数据库配置：经常引起整个系统运行缓慢，一些诸如oracle 的大型数据库都是需要DBA进行正确的参数调整才能投产的。

操作系统配置：不合理就可能引起系统瓶颈。

硬件设置：硬盘速度、内存大小等都是容易引起瓶颈的原因，因此这些都是分析的重点。

网络：网络负载过重导致网络冲突和网络延迟。

步骤二：分析问题
当确定了问题之后，我们要明确这个问题影响的是响应时间吞吐量，还是其他问题？是多数用户还是少数用户遇到了问题？如果是少数用户，这几个用户与其它用户的操作有什么不用？系统资源监控的结果是否正常？CPU的使用是否到达极限？I/O 情况如何？问题是否集中在某一类模块中？ 是客户端还是服务器出现问题？ 系统硬件配置是否够用？实际负载是否超过了系统的负载能力？ 是否未对系统进行优化？

通过这些分析及一些与系统相关的问题，可以对系统瓶颈有更深入的了解，进而分析出真正的原因。

步骤三： 确定调整目标和解决方案
得高系统吞吐量，缩短响应时间，更好地支持并发。

步骤四：测试解决方案
对通过解决方案调优后的系统进行基准测试。（基准测试是指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的和可对比的测试）

步骤五：分析调优结果
系统调优是否达到或者超出了预定目标？系统是整体性能得到了改善，还是以系统某部分性能来解决其他问题。调优是否可以结束了。

最后，如果达到了预期目标，调优工作就基本可以结束了。
5.一般瓶颈
性能测试调优需要先发现瓶颈，那么系统一般会存在哪些瓶颈：

硬件上的性能瓶颈：
一般指的是CPU、内存、磁盘I/O 方面的问题，分为服务器硬件瓶颈、网络瓶颈（对局域网可以不考虑）、服务器操作系统瓶颈（参数配置）、中间件瓶颈（参数配置、数据库、web服务器等）、应用瓶颈（SQL 语句、数据库设计、业务逻辑、算法等）。

应用软件上的性能瓶颈：
一般指的是应用服务器、web 服务器等应用软件，还包括数据库系统。

例如：中间件weblogic 平台上配置的JDBC连接池的参数设置不合理，造成的瓶颈。

应用程序上的性能瓶颈：
一般指的是开发人员新开发出来的应用程序。

例如，程序架构规划不合理，程序本身设计有问题（串行处理、请求的处理线程不够），造成系统在大量用户访问时性能低下而造成的瓶颈。

操作系统上的性能瓶颈：
一般指的是windows、UNIX、Linux等操作系统。

例如，在进行性能测试，出现物理内存不足时，虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的响应时间大大增加，这时认为操作系统上出现性能瓶颈。

网络设备上的性能瓶颈：
一般指的是防火墙、动态负载均衡器、交换机等设备。

例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡器没有起到相应的作用，这时可以认为网络瓶颈。 性能测试出现的原因及其定位十分复杂，这里只是简单介绍常见的几种瓶颈类型和特征，而性能测试所需要做的就是根据各种情况因素综合考虑，然后协助开发人员\DBA\运维人员一起定位性能瓶颈。
6.这里就大致根据理论最大QPS，给网站做几个分类

50QPS以下——小网站

没什么好说的，简单的小网站而已，就如同本站这样，你可以用最简单的方法快速搭建，短期没有太多的技术瓶颈，只要服务器不要太烂就好。

50～100QPS——DB极限型

大部分的关系型数据库的每次请求大多都能控制在0.01秒左右，即便你的网站每页面只有一次DB请求，那么页面请求无法保证在1秒钟内完成100个请求，这个阶段要考虑做Cache或者多DB负载。无论那种方案，网站重构是不可避免的。

300～800QPS——带宽极限型

目前服务器大多用了IDC提供的“百兆带宽”，这意味着网站出口的实际带宽是8M Byte左右。假定每个页面只有10K Byte，在这个并发条件下，百兆带宽已经吃完。首要考虑是CDN加速／异地缓存，多机负载等技术。

500～1000QPS——内网带宽极限＋Memcache极限型

由于Key/value的特性，每个页面对memcache的请求远大于直接对DB的请求，Memcache的悲观并发数在2w左右，看似很高，但事实上大多数情况下，首先是有可能在次之前内网的带宽就已经吃光，接着是在8K QPS左右的情况下，Memcache已经表现出了不稳定，如果代码上没有足够的优化，可能直接将压力转嫁到了DB层上，这就最终导致整个系统在达到某个阀值之上，性能迅速下滑。

1000～2000QPS——FORK/SELECT，锁模式极限型

好吧，一句话：线程模型决定吞吐量。不管你系统中最常见的锁是什么锁，这个级别下，文件系统访问锁都成为了灾难。这就要求系统中不能存在中央节点，所有的数据都必须分布存储，数据需要分布处理。总之，关键词：分布

2000QPS以上——C10K极限

尽管现在很多应用已经实现了C25K，但短板理论告诉我们，决定网站整体并发的永远是最低效的那个环节。我承认我生涯中从未遇到过2000QPS以上，甚至1.5K以上的网站

五.性能标准

一.通用互联网服务端性能

1. TPS大于期望值
2. 错误概率小于0.5%
3. 响应时间小于期望值
4. CPU利用率小于75%
5. JVM内存使用率小于80%
6. 平均每核CPU的Load小于1
7. FullGC频率大于半小时每次

二.用户感知正常响应时间的标准

1. 一秒为优秀
2. 三秒为普通
3. 五秒为客户忍受的上限
4. 十秒为垃圾
5. 超过十秒会认为系统崩了

三.用户感知特殊时间的标准

1. 普通业务操作响应时间：5秒内
2. 万级数据量查询业务响应时间：8秒内
3. 百万级数据量业务查询响应时间：10秒内
4. 千万级别数据量业务查询响应时间：20秒内

六．经常遇到的性能问题

一.查询类的接口 更多在意的点是吞吐量和响应时间
1.redis中间件问题
2.mysql性能问题
3.mongodb被击穿
4.单个sql语句体量过大，造成查询缓慢，优化方式是大sql转化为小sql
5.网络带宽过小，导致数据传输缓慢，造成线程等待，从而造成响应时间较长
6.服务器压力过大，造成服务重启
7.海报绘制使用磁盘IO过多，影响接口响应时间
8.大量计算会使用大量CPU，间接影响接口响应时间

二.有数据变动的接口 需要关注一下数据是否丢失
1.类似于交卷接口，用户量过大时，mq会出现一些问题 会造成消息积压：
表象显示就是出结果太慢 数据丢失：表象显示就是没有结果

三.接口参数的准确性
1.账号的权限
2.账号是在对应接口下是否有数据
3.必要时，需要换不同的参数对接口进行测试，从而尽可能多的覆盖接口逻辑，得到的接口性能也会有很大的差别