1.1、性能概述：
性能决定了一个系统支撑其业务的能力。可以描述为系统稳定运行，高并发访问服务
不会出现宕机，用户访问页面需要的时间，系统能够支撑多少用户并发访问。也可以
描述为对资源的消耗。报告cpu，磁盘，内存，IO，网络等。
普通用户关心的是响应时间和稳定性
⚫ 页面还要多久才能加载出来?
⚫ 页面怎么又报502 了?
开发关心的是架构和代码的性能
⚫ 应用架构是否合理？
⚫ 技术架构是否合理？
⚫ 数据架构是否合理？
⚫ 部署架构是否合理？
⚫ 代码是否存在性能问题？
⚫ Jvm 内存分配是否合理？
运维关心的是系统资源的稳定性
⚫ 资源使用率在正常范围吗？
⚫ 数据库连接数正常吗？
⚫ 系统有内存泄露吗？
⚫ 一个节点宕机了，剩下的还能用吗？
1.2、测试目标
通过压测来观察系统能承载的并发量，响应时间，与最大TPS 了解系统各项性能指
标，以此来评估系统的各项能力
发现系统存在的性能问题，包括
1. 连接池问题。包括Tomcat 连接池，Jdbc 连接池，Nginx 连接池，Tcp 连接队列
2. 内存泄露问题。内存泄露指的是系统在长时间运行过程中，内存空间得不到释
放，最终导致可用内存空间耗尽，出现内存溢出
3. 线程死锁问题。线程死锁指的是某些线程因为资源问题长期占用线程锁，导致其
它的线程因为无法拿到锁而出现大面积阻塞
4. 负载均衡问题。流量过高的情况下，因为负载均衡策略设置不当导致每台服务器
接受的流量不均匀，部分机器压力过大而性能急剧下降，部分机器流量过小而资
源浪费
5. 硬件参数配置问题。例如网卡中断不均，swapiness 比例设置不当，进程优先级
设置不当导致的一系列硬件资源性能问题
1.3、性能测试方法
1.3.1、并发测试
1. 广义并发：多个用户同时触发某个功能，或者在单位时间内同时向服务器发起多
个请求。此时设置的线程数可以表示为并发的用户数
2. 狭义并发：单位时间内多个业务并行处理(这里强调的是业务流程，比如A-B-C
D)。此时设置的线程数可以表示为并行的业务数。
1.3.2、负载测试
持续稳定地增加系统的负载，测试系统性能的变化
找出指标阈值下的系统瓶颈和性能拐点
测试系统所能承受的最大负载量
找到处理极限，为调优提供数据
找出系统在稳定情况下的最大压力值
1.3.3、压力测试
对系统持续保持高压运行，时间可以是几小时甚至几天。观察系统在资源饱和状态下
的处理能力。目的是发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患。同
时观察系统在长时间运行下可能出现的故障（例如反应变慢、内存泄漏系统崩溃）
2.1、需求分析
2.1.1、测试目的
为什么测？目的在于测试系统相关性能能否满足业务需求。通常分以下两种情况：
1. 新项目上线
2. 老项目优化
2.1.2、测试对象
测什么？测试对象可以归结为“业务功能”。测试前需要了解待测试的业务功能（不深入
细节）有哪些，比如“购买商品”、“下单支付”。
有没有必要测？需求来源哪里？有没有数据支撑需求的必要性？
可以从以下几个方面考虑
1. 是否核心功能，是否要求严格的质量
2. 是否常用、高频使用的功能
3. 可能占用系统较多资源的功能
4. 使用人数多还是少
5. 在线人数多还是少
2.1.3、拆分对象
业务上拆分，业务包含哪些流程、环节
登录->搜索商品->提交订单->支付订单->退出
需要从功能实现上来看是怎么实现的。通常这些业务功能操作都对应着一个或多个可
能是不同类型的请求。我们要做的是找出这些操作对应的请求与请求之间的关联性。
2.1.4、指标分析
分析性能需求指标（如“支持300 人并发登录”）是否合理？有没有必要测试这个需
求，考虑需求指标是否合理？有没有数据支撑？支撑数据可以从以下方面考虑：
1. 采样时间段内系统使用人数
2. 采样时间段内系统在线人数
3. 采样时间段内系统(页面)访问量
4. 采样时间段内请求数
2/8 法则
80%的业务量在20%的时间里完成。这里，业务量泛指访问量，请求数，数据量等
2-5-8 原则
当响应时间在2 秒以内，用户会感觉系统速度很快；
当响应时间在2-5 秒，用户会感觉系统的响应速度还可以；
当响应时间在5-8 秒以内，用户会感觉系统的速度很慢，
当响应时间超过8 秒后，用户会认为系统已经无法响应，直接离开
3.1、用例设计
|
用例编号 |
|||||
|
用例名称 |
测试200用户并发登录系统，系统是否能够保持稳定，平均响应时间是否小于3S |
||||
|
用例描述 |
高峰时，200用户并发访问系统，能够正常登录 |
||||
|
前置条件 |
1、登录需要的用户数据已经配置完成 |
||||
|
测试方法 |
jmeter设置200线程，加入集合点，并发访问系统 |
||||
|
用例步骤 |
输入/动作 |
期望的性能指标 |
|||
|
1 |
进入登录页面，输入账号密码，点击登录 |
<=3S |
|||
|
2 |
|||||
|
并发用户数与事务响应 |
|||||
|
并发用户数 |
事务95%响应时间 |
事务最大响应时间 |
平均每秒处理事务数（TPS） |
事务成功率 |
是否通过 |
|
100 |
|||||
|
200 |
|||||
|
250 |
|||||
|
300 |
|||||
|
500 |
|||||
|
并发用户数与应用服务器性能 |
|||||
|
并发用户数 |
事务95%响应时间 |
事务最大响应时间 |
平均每秒处理事务数（TPS） |
事务成功率 |
|
|
10 |
|||||
|
20 |
|||||
|
50 |
|||||
|
100 |
|||||
|
200 |
|||||
|
并发用户数与数据库服务器性能 |
|||||
|
并发用户数 |
事务95%响应时间 |
事务最大响应时间 |
平均每秒处理事务数（TPS） |
事务成功率 |
|
|
10 |
|||||
|
20 |
|||||
|
50 |
|||||
|
100 |
|||||
|
200 |
|||||
4.1、性能监控关键指标
4.1.1、系统指标：系统指标则与用户场景及需求直接相关
u 并发用户数
u 平均响应时间
u 吞吐量
4.1.2、服务器资源指标
CPU使用率： 一般可接受上限85%
内存使用率：一般可接受上限85%
磁盘I/O
网络带宽
4.1.3、JVM应用
Java运行内存划分机制：
堆区内存没有被及时释放，则存在内存泄漏
在性能测试过程中关注JVM堆区的内存，如持续在上升没有下降，则可能存在内存
FULL GC机制：
垃圾回收：将内存中已申请并使用完成的那部分内存空间回收，供新申请使用
垃圾回收机制针对堆区的内存进行的
JVM(JAVA虚拟机)垃圾回收机制
系统在做垃圾回收时，不能处理任何用户业务，如果垃圾回收太频繁，导致系统处理业务能力下降
FULL GC内存比较大，垃圾回收一次时间较长，这段时间不能处理业务，对系统影响比较大，因此在性能测试过程中需要关注FULL GC的频率
4.1.4、数据库指标
Ø 慢查询
Ø 缓存命中率
Ø 数据链接池
Ø Mysql锁
Mysql锁概念：
对比：
l 页面锁：处理效率低，但不会出现死锁
l 处理效率高，但是可能出现死锁
监控点：
需要监控在性能测试过程中，是否死锁出现，如果出现需要对代码优化
4.1.5、压测机资源：
² CPU ---不超过80%
² 内存---不超过80%
² 网络
² 磁盘
标签：响应,性能,系统,基础知识,并发,内存,测试 From： https://www.cnblogs.com/xxstudy/p/16876184.html