怎么做性能测试

一、性能测试概述

软件性能：

系统的性能是个很大的概念，覆盖面非常广泛，对一个软件系统而言，包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等等。

性能测试：

性能测试主要是通过自动化工具模拟多种正常、峰值以及异常负载条件对系统进行操作，以获得系统各项性能指标的一种测试。即对被测试系统按照一定策略施加压力，获取系统响应时间、TPS、吞吐量、资源利用率等性能指标，以期保证系统的性能。

性能测试重要性：

随着公司业务发展越来越快，原有的服务体系已不能满足现在的业务需求，渐渐地暴露出了线上性能不足的问题，所以为了满足用户需求，亟需提升服务整体性能。
性能问题会严重影响用户体验，很多线上用户反馈卡顿等性能问题，性能测试以后会被公司越来越重视。
性能测试涉及面较广，要求性能测试者具备的能力很全面，也是将来发展的趋势，在这里我希望各位都能了解一下。

性能测试概述：

1、为什么进行性能测试

评估系统
系统调优
验证稳定

2、性能测试的目标

寻找瓶颈
性能优化
预测未来

性能测试类型：

1、基本类型

负载测试

压力测试

大数据量测试

疲劳强度测试

失效恢复测试

2、实战类型

单交易基准测试
单交易负载测试
混合交易测试
稳定性测试
高可用性测试
异常测试
批量程序测试
流控超时测试
参数调优测试
……

性能测试指标：

RepsonseTime - RT：响应时间，用户从客户端发起一个请求开始计算，到客户端接收到服务端的响应结束，整个过程所耗费的时间。

Hits Per Second - HPS：用户每秒点击次数，也就是每秒向后台发送的请求次数

QPS：系统每秒内处理查询的次数。

MaxRT：最大响应时间，指用户发出请求到服务端返回响应的最大时间。

MiniRT：最少响应时间，指用户发出请求到服务端返回响应的最少时间。

90%响应时间：将所有用户的响应时间进行升序排序，取 90 % 的位置。

吞吐量：每秒钟系统能处理的请求数/任务数。在测试中，我们往往会比较注重系统接口的QPS/TPS，因为QPS/TPS体现了接口的性能，QPS/TPS越大，性能越好。

响应时间：服务处理一个请求或一个任务的耗时。

错误率：一批请求中结果出过错的请求所占比例。

二、性能测试的步骤：

1、前期准备

性能测试虽然是核心功能稳定后才开始压测，但是在需求阶段就应该参与，这样可以深入了解系统业务、重要功能的业务逻辑，为后续做准备。

准备的内容：
测试策略（方案）

2、性能需求分析（评审）

明确性能测试范围、目标。

关注点：

测试范围、目标的合理性：
推荐方式：引导产品、需求或者开发出压测目标（分别是单场景、混合场景、稳定性场景的），自己给建议，大家一起确定一个当前合理的目标。

定性能指标：

定性能指标，分为迭代项目和新项目，迭代项目就根据生产监控、日志分析来评估指标，这里需要做容量规划，新项目单独评估。

3、熟悉系统架构

1、做性能测试，必须要熟悉项目的架构，这样你才知道监控哪些服务器，以及准备监控方案（监控方式及监控的性能指标点）；

2、包含具体用到的web服务器、应用服务器、缓存数据库服务器、数据库服务器、文件服务器等；

3、主流的技术栈：nginx、dubbo、mysql、redis、jvm等等

4、制定性能测试方案

项目背景及架构分析，
需要的资源，
技术策略（比如压测、监控、分析工具选择等），
场景设计，
计划什么时候做什么事等等。

5、搭建测试环境，准备测试数据

1、搭建测试环境是测试必备的技能，当然，如有困难，你也可以找运维、开发一起配合；

2、测试数据分为基础环境数据和业务数据；

3、基础环境数据可以从功能测试的库导过来，改一些配置即可；

4、业务数据包含：存量数据+容量规划数据，比如一个查询接口，都是并发100用户，对应的表数据量是1万和100万，压测结果是不一样的；

5、数据量要参考生产环境，如果是新项目，除了空库压，最好也做一下存量数据压。

6、压测脚本开发

主流程稳定后，调试被测接口、开发压测脚本（也可以在功能测试环境进行）；

客户端并发工具，推荐用Locust，主流、开源、轻量、免费、功能强大；

根据实际情况，对脚本调整，比如：参数化、关联、事务、检查点、思考时间、信息头管理器等；

7、预压测（基准测试）

少量并发（比如1个用户），压测10分钟，
第一：可以看压测环境功能是否通；
第二：估算并发过程中需要多少参数化数据的数据量；

8、执行压测并监控

场景设计好后，就可以执行压测了，然后监控查看测试各项指标是否满足需求；如果不满足，可以结合表象及根据自己的经验直接去看预估的瓶颈点；
否则，从请求开始，一步一步排查请求流经的节点，包括服务器资源（cpu、内存、磁盘io、网络）是否存在性能瓶颈、是否存在队列、线程池、连接池、线程死锁、数据库死锁、慢sql、长事务等性能问题；
用什么工具监控？我大部分都是用的命令，为了方便，也会写shell脚本来监控；
linux服务器，常用的命令是top、vmstat、free、df、sar、iostat、netstat等，一般是多个命令配合着用；
java应用：jvisualvm、jconsole、jmap、jstat、jstack等，以及自己写的一些shell脚本； redis、mysql、jvm等等。

9、分析定位

基于上一步的监控数据，对瓶颈进行分析、定位，模块隔离分析、日志分析、内存分析、线程栈分析、代码跟踪等等；
这个真需要实战积累，没有捷径！

10、性能优化

定位到问题了，大部分情况下，优化方案也就有了，测试可以把自己建议的优化方案告诉开发，开发会结合自己的方案，一起做优化方案评估；

如果测试没有优化方案，那就把问题反馈给开发吧，但是也好好学学开发的优化思路，这就是成长的过程。

11、性能回归

开发优化后，复测。

12、编写性能报告

测试结果是多少？
测试是否通过？
发现了什么性能问题？
原因是什么？
如何优化解决的？
系统性能提升了多少倍？
优化方案务必写详细，以便上线同事知道，把优化同步到其它各个环境。

三、经典案例：

性能测试要求有很强的基本功和知识面，很考察一个人的功底。
现象1：

现象2：

排查思路：
1、通过压测来模拟犯罪现场。
2、通过线上问题现象来深入分析。

压测过程：






通过线上问题现象来深入分析：
通过线上问题现象二，我们看到close_wait数非常大，已经达到了10万多个，造成这种现象的原因，我在这里详细说一下：
这里需要你知道socket通信的知识，即三次握手，四次挥手的具体通信流程。

那到底什么原因会造成close_wait增多呢？
直接原因：
服务端的第二个FIN报文一直没有给客户端发，而客户端httpClient一般都有请求超时时间，默认是5s，超时之后就会抛出异常，关闭连接，关闭连接导致客户端发送了FIN报文，服务端收到后会返回ACK报文，但是由于服务端处理请求的线程还处于阻塞的状态，所以服务端当前的连接状态是close_wait状态，这个过程就一直这样循环下去，导致服务端的close_wait会不断增多。

间接原因：那什么原因造成服务端阻塞呢？
答：
1、服务端线程池问题
线程池设置不合理，设置的过低造成排队阻塞现象；这里就用到线程池的知识了，线程池设置一般根据服务器的CPU核数来设定，一般线程池的大小设置成为CPU的核数。
2、服务端连接池问题
比如你的数据库连接池设置的过小，每来一个请求就创建一个连接，特别是高并发下，很快就会把连接池打满了，连接池被打满了，即没有可用的连接了，后面来的请求就会一直阻塞，客户端的请求就会一直等待，造成客户端等待超时，主动关闭连接并发送FIN报文…这样恶性循环下去，服务端的close_wait会越来越多。
3、资源释放问题
服务端没有释放资源，比如数据库连接池打满，每个线程处理完没有释放资源，造成线程阻塞。
4、锁或同步代码块问题
高并发下同步代码块中使用了重量级锁，没有使用轻量级锁或自旋，或者由于同步代码块逻辑比较重，出现了死锁，这样同步代码块就会一直阻塞下去。
以上几种情况，在高并发下，服务端资源使用不当或消耗殆尽，很容易被打挂，造成死锁、服务hang住，对新来的请求不再处理了，也处理不过来了，造成迟迟不会主动给客户端发送第二个FIN报文，最终造成服务端close_wait数目越来越多。

思考：
假设我们的服务遭到别人恶意攻击了，那我们该怎么做才能使服务能抗住这些攻击而不让服务挂掉呢？
我的回答是：打铁还需自身硬,无须扬鞭自奋蹄~

最后附上性能测试技能树：