性能测试

性能测试

 

1、jmeter报告上的指标有哪些？

1) 请求数、平均响应时间、百分之90、95、99的响应时间、吞吐量、错误占比

2) jmeter 资源插件：cpu、内存、交换内存、磁盘IO

 

2、90%代表什么意思？

将所有请求的响应时间从小到大排序，取排在第90百分位的响应时间值

 

3、性能测试关注哪些指标？

1、吞吐量、响应时间、错误率、资源占用率

2、资源占用率包含的指标：

(1) cpu：cpu占比、cpu平均负载、

(2) 内存：剩余内存、交换内存、从磁盘到内存，从内存到磁盘的页面数

(3) IO：cpu等待IO的时间占比、IO磁盘利用率、平均IO队列长度，>1有堆积的可能

3、响应时间默认小于1秒

4、错误率小于0.01～0.05

5、资源占用率，cpu、内存、磁盘、网络，小于80%

补充：

(1) 吞吐量

① tps 每秒事物数

② qps 每秒查询数

③ rps 每秒请求数

(2) 大型OA 50～200

 

4、你用什么命令查看这些资源指标？

 1、CPU 相关指标（vmstat）

· us（用户态 CPU 使用率）

• 不超过80%

· sy（系统态 CPU 使用率）

• 不超过20%

· id（CPU 空闲时间百分比）

• 30% 以上

· wa（CPU 等待 I/O 操作完成的时间百分比）

• wa 值应尽量低，通常在 5% 以下较为理想。如果 wa 值较高，说明 CPU 花费了较多时间等待 I/O 操作完成，可能存在磁盘 I/O 瓶颈。

· 命令Top：动态查看cpu所占百分比，不超过85%  虚拟核，top -p pid

· 命令uptime：Cpu 1分钟、5分钟、15分钟的平均负载，要低于物理核，lscpu 可查看物理核和虚拟核

 

 2、内存相关指标（vmstat）

free（空闲的物理内存大小）

• 留物理内存的 20% 作为空闲内存，以应对突发的内存需求。

· swpd（已使用的交换内存大小）

• 理想情况下，swpd 应尽量为 0。如果 swpd 值较大且持续增长，说明系统物理内存不足，开始频繁使用交换空间，这会严重影响系统性能。

si（每秒从磁盘交换到内存的页面数）和 so（每秒从内存交换到磁盘的页面数）

• 正常情况下，si 和 so 的值应该接近于 0。如果这两个值持续较高，表明系统正在频繁进行内存和磁盘交换空间之间的数据交换，意味着系统内存紧张。

 

3. I/O 相关指标（vmstat）

• 如果cpu等待IO的时间占比5% 以下比较理想，超过10%～20%，则说明磁盘I/O存在问题，考虑提高磁盘I/O读写性能
• 磁盘利用率 %util 不超过 70%
• 平均IO队列长度，>1有堆积的可能

 

4、进程相关指标（vmstat）

• r（运行队列中的进程数）
  • 一般来说，r 值应保持在 CPU 核心数的 2 倍以内。例如，对于一个 4 核 CPU 的系统，r 值长期超过 8 可能意味着系统负载较高，有进程在排队等待 CPU 资源。
  • b（等待 I/O 的进程数）
    • b 值通常应尽可能接近于 0。如果 b 值持续较高，说明有较多进程在等待 I/O 操作完成，可能存在磁盘 I/O 瓶颈。

 

 

5、怎么制定业务指标？

1. 测试登录开户申购业务，在19点～21点高峰值，登陆4万8次请求，开户3万，购买6万次请求。就可以知道每个业务接口最大tps。 登录最大tps=48000/7200=6.7；开户最大tps=30000/7200=4.1；购买最大tps=60000/7200=8.3

2. 混合业务怎么算比例？

(1) 19点～21点，登录请求数48000，开户请求数3000，购买请求数6万，

(2) 登录业务比例=48000/(48000+30000+60000)= 35%

(3) 开户业务比例=30000/(48000+30000+60000)= 22%

(4) 购买业务比例=60000/(48000+30000+60000)= 43%

3、最大并发人数计算方式

(1) 平均日活7000，19点～21点，是7200秒，登录开户购买7分钟，420秒

(2) 并发人数 = (7000*420)/7200=408 不可能7000人都来，取80%=323~408

6、你们项目是怎么开展性能测试的？你们项目的压测场景是怎么设置的？

(1) 确认业务指标。同上。

(2) 平均响应时间小于1秒；

(3) 错误率0.01～0.05

(4) cpu、内存、磁盘、网络小于80%

(5) 基准测试。无压力情况下的1个请求，持续10分钟。

① 平均响应时间328ms

(6) 容量测试。阶梯形势不断压测。

① 并发350，最大TPS 是420

② 平均响应时间800ms多

③ 性能拐点，并发400，错误率升至1.2%

(7) 稳定性测试。覆盖业务指标的最优持续7个小时测试。

① 并发350的条件下，7小时平均tps 是387

② 平均响应时间900ms多，系统无报错

③ 内存从4.2增到4.8，正常

(8) 异常测试

① 在高峰值，模拟数据库宕机，自动恢复后，业务是否可以正常进行。网络IO在数据库服务关闭和重启会陡增，之后会恢复到正常。

② redis 切换。在切换的过程中，0错误，响应时间会增大一些，tps会降低一些，响应时间超过3秒，影响时长40秒。

6、怎么实现每秒并发400？

 

 

(1) 一共设置400个线程

(2) 每秒增加10个，增加到400后持续5分钟

(3) 每秒减掉10个线程

7、jmeter 与locust ，结果差异很大的原因？

特性	JMeter	Locust
协议实现	基于Java线程（1线程=1用户）	基于Python协程（1线程模拟数千用户）
资源消耗	高内存（每个线程独立栈空间）	低内存（协程轻量级切换）
并发模型	阻塞式（受限于线程数）	非阻塞式（异步IO）

 

 

8、你们项目中最大最优并发数是如何评估的？

最大：是系统奔溃之前

最优：是符合业务指标

 

 

9、你们在项目中有没有碰到高并发是怎么处理的？

（1）、并发人数大于500～1000的时候，单机持续cpu、内存、网络大于80%，用分布式压测。

（2）、master、slave 安装版本相同的jmeter、jdk

（3）、master上修改jmeter配置文件，添加slave的ip、端口号

（4）、slave上修改jmeter配置文件，配置端口号

（5）、在slave 上启动jmeter服务

（6）、master 执行jmx压测文件

 

10、你们在性能测试中发现了什么问题是怎么解决的？

在压测一键赎回功能。

(1) 从jmeter插件监控图，响应时间陡升、tps陡降。

(2) 正常情况下，top =80% uptime 每一分钟cpu的平均负载值是3点多，但是top = 50%, uptime 每一分钟cpu的平均负载值就3点多了，可能发生了等待。vmstat cpu wa 高达45%

(3) 原因：大额赎回，触发系统高频校验

(4) 建议，单笔超过1000万，启用异步清算流程

补充：

mysql慢查询定位

grafana mysql最大连接数、mysql等待锁、慢查询（可以在配置文件设置慢查询时间，会将慢查询倒在一张表里，帮助开发定位具体sql）不要超过1s。type=all 全表搜索导致。

redis 分析程过

1、错误率飙升

2、看jenins日志没有问题

3、看服务器日志，是连接池不够

4、CONFIG GET * 查看redis 连接数，默认1万，并发3000，也够

5、查看项目的配置文件，redis 最大池子配置的1000

 

11、你们是怎么分析性能瓶颈以及进行性能调优的？

思路：网络->服务器配置->压力机配置->JVM->中间件->数据库->系统架构nigx

 

12、redis

(1) 通用操作

① keys *、del key、exists key、expire key、ttl key、type key

(2) string

① set key、get key

(3) hash

① hset key field value、hget key fileid

(4) list

① lpush key element、rpush key element、lpop key、rpop key、lrange key start end

(5) 无序set(添加多个标签、黑白名单、抽奖去重)

① sadd key member

② srem key member

③ sinter key1 key2 交集

④ sdiff key1 key2 差集

⑤ sunion key1 key2 并集

(6) 有序sortedset(实时排名)

① zadd key score member、zrem key member、zrevrange key 0 9 前10名、zscore key member