本文详细介绍了性能测试的步骤，包括确定目标和指标（如响应时间、吞吐量）、设计测试场景、配置测试环境、编写测试脚本以及分析和优化。重点讲解了并发处理、资源使用和监控的重要性。
性能测试
以下是一个基本的性能测试过程，旨在帮助了解性能测试的具体流程和步骤。
1、确定性能测试目标及指标
首先，需要确定性能测试的目标和指标，包括响应时间、吞吐量、并发用户数等方面。这些指标应该根据业务需求和用户场景进行设定，并设定相应的阈值。
如果有明确的性能要求，就按照需求进行测试，如果没有具体需求，则可以先做一下基准性能测试，了解服务器的性能后，由测试人员初步定一个测试目标，然后拉通产品，开发评审。
性能测试场景：
1、追求更大的并发*【担心用户太多，搞垮系统用户量太多，担心处理不过来】*
*2、*追求更短的响应时间【觉得系统响应太慢】
*3、*追求更少的资源【成本太高，需要服务器太多】
性能测试指标：
1.1、响应时间
-
狭义：用户进行操作后，得到最后结果之间所消耗的时间
-
广义：主要包含浏览器传输时间，服务器处理时间，服务器传输时间，数据库处理时间等多时间汇总所得到的结果
-
我们的响应时间通常是我们进行性能测试最直接的判断结果：
- 例如我们查询一万条数据时所需要得到的响应时间在3s之内
但我们还需要注意一点：
- 我们所获取的响应时间并不能是单次运行所得到的时间
- 而是在多次运行下，所得到的所有运行时间的平均值（Jmeter会有一个字段存储平均响应时间）
1.2、吞吐量
我们来简单介绍一下吞吐量：
- 吞吐量指单位时间内处理客户端的请求数量，可以直接体现出系统的性能承载能力（单位：秒、每秒处理的请求量）
吞吐量主要分为两种：
- TPS每秒事务数，用户操作伴随数据变化，例如：淘宝下单，40万订单/秒
- QPS每秒查询数，用户查询数据，例如：打开淘宝查看某个商品页面
我们首先来介绍TPS：
- 即控制服务器每秒处理的事务请求的数量
- 该计算仅仅针对事务的数量进行计算，一次事务（一次点击）可能会出现1个或多个请求，而这些请求都被划分为一次事务
- 如果是单接口级，则TPS即该接口的请求数；如果是业务级，则是所有接口组合起来的业务数
我们采用一张图片解释：
我们再来介绍QPS：
- 即控制服务器每秒处理的指定请求的数量
- 该计算是指针对某单一接口请求，去统计该单位时间内所处理的请求个数
我们同样采用一张图片解释：
1.3、资源利用率
我们来简单介绍一下资源利用率：
- 即计算机内各种资源的使用情况
- 通常是一个比率值，采用当前使用资源数/计算机全部资源数来获取
我们常见的一些计算机资源包括有：
- CPU使用率
- 显卡使用率
- 内存使用率
- 磁盘IO效率
- 网络传输率
1.4、并发处理能力
海量用户使用系统时候，在系统不崩溃情况下，能够支撑多少人同时使用
单位：秒
（1）同时在线：
例子：10w人在线观看视频；session会话信息保存到 服务器存储 里面
（2）同时操作：
例子：支付宝同时操作付款
1.5、中间件的使用情况
常用的中间件例如Tomcat、Weblogic等指标主要包括JVM、ThreadPool和JDBC，具体如下：
| 一级指标 | 二级指标 | 单位 | 释义 |
|---|---|---|---|
| GC | GC频率 | 每秒多少次 | java虚拟机垃圾部分回收频率 |
| GC | Full GC频率 | 每小时多少次 | java虚拟机垃圾完全回收频率 |
| GC | Full GC平均时长 | 秒 | 用于垃圾完全回收的平均时长 |
| GC | Full GC最大时长 | 秒 | 用于垃圾完全回收的最大时长 |
| GC | 堆使用率 | 百分比 | 堆使用率 |
| ThreadPool | Active Thread Count | 个 | 活动的线程数 |
| ThreadPool | Pending User Request | 个 | 处于排队的用户请求个数 |
| JDBC | JDBC Active Connection | 个 | JDBC活动连接数 |
各项指标参考标准：
（1）当前正在运行的线程数不能超过设定的最大值
系统性能较好的情况下，线程数最小值设置50和最大值设置200比较合适。
（2）当前运行的JDBC连接数不能超过设定的最大值
系统性能较好的情况下，JDBC最小值设置50和最大值设置200比较合适。
（3）GC频率不能频繁，特别是FULL GC更不能频繁
系统性能较好的情况下，JVM最小堆大小和最大堆大小分别设置1024M比较合适。
1.6、数据库指标
常用的数据库指标主要包括SQL、吞吐量、缓存命中率、连接数等等，具体如下：
| 一级指标 | 二级指标 | 单位 | 释义 |
|---|---|---|---|
| SQL | 耗时 | 微秒 | 执行SQL耗时 |
| 吞吐量 | QPS | 个 | 每秒查询次数 |
| 吞吐量 | 每秒查询次数 | 个 | 每秒事务次数 |
| 命中率 | Key Buffer命中率 | 百分比 | 索引缓冲区命中率 |
| 命中率 | InnoDB Buffer命中率 | 百分比 | InnoDB缓冲区命中率 |
| 命中率 | Query Cache命中率 | 百分比 | 查询缓存命中率 |
| 命中率 | Table Cache命中率 | 百分比 | 表缓存命中率数 |
| 命中率 | Thread Cache命中率 | 百分比 | 线程缓存命中率 |
| 锁 | 等待次数 | 次 | 锁等待次数 |
| 锁 | 等待时间 | 微秒 | 锁等待时间 |
参考标准：
（1）SQL耗时越小越好，一般情况下微秒级别；
（2）命中率越高越好，一般情况下不能低于95%；
（3）锁等待次数越低越好，等待时间越短越好。
1.7、稳定性指标
这里的稳定性是指最短稳定时间，即系统按照最大容量的80%或标准压力(系统的预期日常压力)情况下运行，能够稳定运行的最短时间。
一般来说，对于正常工作日(8小时)运行的系统，至少应该能保证系统稳定运行8小时以上；对于7*24运行的系统，至少应该能够保证系统稳定运行24小时以上。如果系统不能稳定的运行，上线后，随着业务量的增长和长时间运行，将会出现性能下降甚至崩溃的风险。
参考标准：（1）TPS曲线稳定，没有大幅度的波动；（2）各项资源指标没有泄露或异常情况。
2、设计测试场景
在设计测试场景时，需要考虑到被测系统的不同使用情况、用户行为、负载分布等因素。根据实际业务场景，设计合理、有效的测试场景，并准备充分、真实的测试数据。
2.1、需要根据真实的业务，来设计需要测试的场景，不是所有业务需要进行性能测试，只需要部分场景例如：业务中使用量最大的功能、业务中比较重要的功能、使用量不大但是根据经验可能会出现问题的业务场景、秒杀、抢购，打卡签到等瞬时并发量很大的场景。
2.2、还需要熟悉项目的架构，这样才知道需要增加监控服务器的性能，设计监控的方案
3、配置测试环境
配置性能测试环境，包括硬件、操作系统、网络等方面，以确保测试环境的稳定和可靠性。同时设置监控和记录系统的资源占用率等数据，以便后续分析测试结果。
3.1 一般需要申请单独的性能测试环境进行测试，跟功能测试环境区分开来
4、编写测试脚本
根据测试场景和目标，编写相应的测试脚本，并针对不同的测试场景设置合理的线程数、Ramp-up 时间等参数。
4.1、首先需要保证功能稳定，主流程可用，然后再进行测试脚本开发
4.2、常用的客户端并发工具：Jmeter，Loadrunner。这两个只是并发工具，并不能完全代表性能测试
4.3、线程数需要根据TPS来定义，10000用户x5%=500(用户级TPS)，注意哦，这里是TPS，而不是并发线程数。如果这时响应时间是100ms，那显然并发线程数是500TPS/(1000ms/100ms)=50(并发线程)。
#jmeter使用
1、（普通场景）并发逐步增压：jmeter的阶梯增压工具：Custom Thread Groups==》可以让目标并发量在一定时间内分段逐步增压到指定并发
2、（限时秒杀，抢购场.景）需要断崖式上升==》同步定时器
3、不用接口的调用程度不同：吞吐量控制器（调控每个接口被调用的比例）
4、登录接口不同请求参数如何设置：CSV Data Set Config 选择本地创建好的文件，设置变量名
5、进行性能测试
执行性能测试，并根据设定的测试场景和指标收集相关数据。在测试过程中，需要根据实际情况进行调整和优化，并确保测试结果的可靠性和有效性。
5.1、执行压测时，需要监控查看测试各项指标是否满足需求；如果不满足，可以结合表象及根据自己的经验直接去看预估的瓶颈点；否则，从请求开始，一步一步排查请求流经的节点，包括：
- 服务器资源（cpu、内存、磁盘io、网络）是否存在性能瓶颈、
- 是否存在队列、线程池、连接池、线程死锁、数据库死锁、慢sql、长事务等性能问题；
- 链路监控工具，可以监控是哪个阶段异常导致的响应时间长
5.2、常见的监控命令：
-
linux服务器：top、vmstat、free、df、sar、iostat、netstat等，一般是多个命令配合着用；
top:是linux上的任务管理器，查看内存、cpu、进程等信息 在top命令执行后，输入大写M可按进程的内存使用率排序，大写P按进程的cpu使用率排序 vmstat:看到整个机器的CPU,内存,IO的使用情况。 常用 vmstat 2 1:表示2表示每个两秒采集一次服务器状态，1表示只采集一次。 free:查看内存 df -hl：查看磁盘使用空间 sar:查看网络 iostat:查看io磁盘 netstat -ano:查看端口 -
java应用：jvisualvm、jconsole、jmap、jstat、jstack等
6、分析测试结果
对测试数据进行分析，包括响应时间、吞吐量、错误率等方面。还需要将测试结果与预设的阈值进行比较，找出性能问题的具体原因，并提出相应的解决方案和优化建议。
6.1、性能测试是否通过标准：
1、请求错误率
2、响应时间在接受范围
3、资源使用在使用范围：服务器监控
6.2、判断是否单用户费并发情况下已经有性能问题了，如果是的话，大部分问题出在程序代码和sql上，需要进行优化；如果是并发状态下出现问题，则需要进一步分析，是否是 中间件的问题，还是代码问题
6.3、常见的性能问题
-
硬件问题：服务器资源（cpu、内存、磁盘io、网络）是否存在性能瓶颈、
-
运行环境问题：是否存在队列、线程池、连接池、线程死锁、数据库死锁、慢sql、长事务等性能问题；
-
代码问题
- 循环中初始化大的结构对象，数据库连接等
- 资源不释放导致的内存泄露等
- 没有基于场景需求来适度通过缓存等方式提升性能
- 长周期事务处理耗费资源
- 处理某一个业务场景或问题的时候，没有选择最优的数据结构或算法
7、提出优化建议
根据测试结果，提出相应的性能优化建议。这通常包括系统架构的调整、代码的优化、资源的调配等。需要注意的是，在提出优化建议时，需要考虑到业务需求和用户体验等因素，并确保其可行性和成本效益。
具体问题具体分析
7.1、常见接口优化方式
- 批处理：批量操作数据库
- 异步处理：即将不关联的接口通过异步方式进行处理
- 空间换时间：合理利用缓存
- 预处理：提前处理好，接口直接获取
- 池化思想：线程池，数据库连接池等
- 串行改并行：不同接口并行查询
- 索引：sql索引优化
- 避免大事务：减少事务的运行时间，将查询任务放在外面
- 优化程序结构：code review
- 深分页问题：分页问题
- sql优化
- 锁粒度避免过粗
8、进行反复测试和调整
在提出优化建议后，根据相应的方案进行调整和优化，并在此基础上进行反复测试，以确保测试结果的有效性和可靠性。反复测试和调整过程中，需要不断地监控和记录测试数据，以便及时发现和解决问题。
总之，性能测试是一个复杂的过程，需要充分考虑被测系统的特点和实际情况，设计合理的测试场景，收集可靠的测试数据，进行系统性地分析和提出优化建议，并在此基础上进行反复测试和调整。通过科学、系统、有效的性能测试过程，可以帮助您更好地发现和解决系统中的瓶颈和性能问题。
9、输出性能测试报告
- 测试结果是多少？测试是否通过？
- 发现了什么性能问题？原因是什么？如何优化解决的？
- 系统性能提升了多少倍？
进行反复测试，以确保测试结果的有效性和可靠性。反复测试和调整过程中，需要不断地监控和记录测试数据，以便及时发现和解决问题。
总之，性能测试是一个复杂的过程，需要充分考虑被测系统的特点和实际情况，设计合理的测试场景，收集可靠的测试数据，进行系统性地分析和提出优化建议，并在此基础上进行反复测试和调整。通过科学、系统、有效的性能测试过程，可以帮助您更好地发现和解决系统中的瓶颈和性能问题。
9、输出性能测试报告
- 测试结果是多少？测试是否通过？
- 发现了什么性能问题？原因是什么？如何优化解决的？
- 系统性能提升了多少倍？
- 优化方案务必写详细，以便上线同事知道，把优化同步到其它各个环境。
651
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
