性能测试面试题（一）

1.性能测试的应用领域有哪些？

能力验证：通过实际的测试结果证明自己系统的预期能力

瓶颈分析：通过一系列的测试手段发现系统存在的性能瓶颈（并发，负载，压力，失效恢复）

性能调优：通过一系列的技术手段优化系统性能，包括响应时间，吞吐量，资源利用率

容量规划：为了符合未来的规划预期（用户数，市场占有率），对资源做相应的调整。

2.交付一个性能测试项目，请阐述你的性能测试流程

    1：分析需求

    2：制定测试计划和方案（人力资源，时间资源，测试机器资源）

    3：设计性能测试场景和用例（并发，负载，压力，稳定性测试）

    ===搭建环境===

    4：准备用户数据（如何确定用户并发数）

        （1）线上的注册用户数的10%做测试环境的在线用户

        （2）根据高峰时间段和业务量，计算平均并发和峰值并发

    5：设计性能测试脚本（jmter或者lr）

        （1）线程，请求，关联，断言，参数化，报告

        （2）不同的线程组设计不同的测试类型

    6：运行，监控测试数据

        jmeter监听器，jtl数据，grafana+jmeter，非gui

    7：分析性能瓶颈

        吞吐量瓶颈，响应时间瓶颈，资源利用率瓶颈

    8：性能调优

        （1）吞吐量调优：中间件，jvm，网卡带宽

        （2）硬件调优：cpu，磁盘，IO，TCP连接，swap内存

    9：出具性能测试报告和总结

3. jmeter如何设计性能测试场景？

并发测试：基础线程组（强调单位时间的并发，不存在绝对并发）

基准测试：反复对比结果，验证调优结果是否通过（tps是否提升，响应时间是否下降）

负载测试：持续不断地增加负载，发现性能瓶颈（阶梯加压线程组，Concurrency Thread Group）

    并发用户模式的负载：不断增加并发用户数，发现瓶颈

    吞吐量模式的负载：不断增加每秒请求数（rps）对服务端施压，发现tps瓶颈

压力测试：tps瓶颈点上持续负载

    稳定性压力测试：tps保持高压稳定。一般取最大tps的80%持续运行

    破坏性压力测试：目的是只需要服务端出现异常
    
失效恢复测试：出现异常之后，系统可以很快的恢复

容量规划测试：50万，高峰时间段2小时

4.解释常用的性能指标的名称与具体含义

吞吐量

 hps：点击率

 rps：每秒请求数

 qps：每秒查询接口数

 tps：单位时间完成的请求（事物）数
 
响应时间：页面渲染时间，tcp连接时间，sql查询时间，服务端处理时间

错误率：没有正常返回200的都是错误

cpu利用率

IO平均时间

内存利用率

。。。。。

5.什么是集合点？设置集合点有什么意义？jmeter中如何设置集合点？

让用户尽可能在同一时间点发起请求

6.集合点的等待时间怎么设置？

等待时间=0，线程数达不到集合人数就会一直等待

 等待时间>0，线程数在等待时间范围内集合发起

7.什么是压力？有哪些压力模式？

服务端接收请求叫压力

 并发用户模式，加人数

 吞吐量模式，加请求

8.你在性能测试中遇到哪些性能问题？

响应时间过长

 tps过低

 tps毛刺过多

 tps经常出现断崖式下跌

 进程无缘无故失踪

 内存溢出

 cpu利用率过高

9.针对大并发压力测试，主要是从哪几个方面去考虑点?

 考虑并发用户数的设计

  考虑测试场景

  考虑服务端的资源

  考虑网络环境（内网还是外网）

  机器是否足够，是否需要分布式压测

10.举例说明jmeter的定时器用法？

固定定时器：模拟用户思考时间

rps定时器：控制每秒请求数

tps定时器：控制每秒吞吐量

11.jmeter中如何监控linux资源？

serveragent插件在服务器安装启动

保证防火墙对4444端口开放，否则会连接拒绝

本机启动监控

12.什么是性能测试？

功能测试，安全测试，接口测试，性能测试都是测试目的

性能测试的目的是测试系统性能

压力测试，负载测试，并发测试都是方法

通过方法去实现目的

13.怎么做参数化？

csv配置元件，循环读取参数

csv函数 只对线程生效，多线程读取

14.jmeter负载测试中怎么保持session会话？

对session唯一性有要求的接口

（1）:脚本保存session，cookie管理器并发读取session。吞吐量相对较低

（2）正则提取保存为全局属性，cookie管理器并发读取session。吞吐量正常

15.什么是关联，如何动态关联？有哪几种关联的方法？

上下文关联，正则表达式关联，json关联，xpath关联

16.什么是Ramp up？你如何设置？

线程启动的时间

请求的单位时间

17.如何识别性能瓶颈？

tps下降?

响应时间上升?

负载越来越高，响应时间越来越长，tps没有变化?

随着负载升高，tps却不变，意味着单线程的tps是越来越低的。。。

总的tps/线程数=性能瓶颈点

Transaction Throughput vs Threads

18.简述堆区的空间分配和gc原理

年轻代

    eden和2个s区

    2个s区轮转回收垃圾

老年代

1：超出年轻代年龄阀值的对象

2：对象大小超出年轻代对象阀值

fullgc

1:老年代满了

2：年轻代进入老年代的对象超出了老年代剩余空间大小

老年代都是大对象，所以fullgc时间很长，大约是年轻代时间的十倍。

gc的时候，所有线程暂停

19.什么是内存溢出

堆内存溢出

栈内存溢出

线程栈。线程启动多少由栈空间决定

20.简述cpu的工作原理

通过cpu线程去调度运行进程/线程，一个cpu线程同一时间只能调度一个运行线程

运行线程数超出了cpu线程，会启动时间片分配机制

21.什么是上下文切换？哪些场景会存在上下文切换？

进程间的切换，交接内存/io

线程切换

    线程在进程内共享资源。线程的cpu时间片用完了就会放弃cpu，进入队列等待

内核切换，系统调用。

    用户空间向内核空间发起调度请求，切换到内核空间给予api，再次切换到用户空间调度api。一次系统调用产生两次切换

22.简述平均负载和利用率

平均负载：单位时间内正在调度cpu的线程+队列中的线程

cpu平均调度时间。

如果cpu分配了100个时间片，有50个花在了切换上，那么利用率只有50%

23.什么是swap空间？oomkiller了解吗？怎么开启swap空间

磁盘空间中开辟的虚拟物理内存。si换出，so换入

swap空间用完了，系统会杀死占用内存最高的进程

swapoff -a 关闭swap

swapon -a 开启swap

swap空间比例：cat /proc/sys/vm/swappiness 物理内存使用比例超出swappiness，就会启用swap

设置临时比例：sudo sysctl vm.swappiness=10

24.进程的优先级如何设置？

调整nice值，改变优先级pr

nice -19 ---- 19

pr越高，进程优先级越低，cpu时间片越少；反之优先级越高，时间片越多

25.吞吐量大幅度波动有哪些原因？

内存不足

tomcat连接数不够

网卡队列不够

线程过多

26.哪些现象说明了IO瓶颈？

await:io等待时间，队列时间+io处理时间

svctm：平均io的时间

await-svctm：得到的是io队列时间，差值越大，表示io处理效率越低

%util：io的使用百分比，越高表示磁盘越繁忙

27：了解哪些资源监控命令？

top

lscpu

mpstat

vmstat

pidstat

iostat

netstat

28.如何用命令行生成测试报告？jtl文件怎么分析？

 jmeter  -n -t  XX.jmx -l XX.jtl  -e -o httpreport

29.简要描述如何分布式执行脚本

  slave配置

  master配置

30.设计一个持续集成框架（描述清晰，能画出来）

    docker+jenkins+gitlab+ant+jmeter+nginx+php

性能测试中Linux命令

主动上下文切换:cswch/s 当某一任务处于阻塞，比如说， I/O、内存等系统资源不足时，就会发生自愿上下文切换 将主动让出自己的CPU资源

被动上下文切换:nvcswch/s CPU分配给某一任务的时间片耗尽，因此将强迫该进程让出CPU的执行权。比如大量进程争抢 CPU

strace -tt -f -p 21156 查看系统调用信息

strace -o strace.log -tt -p 【pid】

dstat -y 查看系统中断和上下文切换

pidstat -w 统计进程的上下文切换

pidstat -wt 统计threads的上下文切换

pidstat -p 7826 -w 1 10 显示进程的上下文切换

sar -w 1 统计proc和上下文切换

grep ctxt /proc/$pid/status 统计上下文切换数

watch -d cat /proc/interrupts 统计进程中断的方式

apt install sysbench sysstat 安装sysbench，模拟多线程切换

sysbench --threads=10 --max-time=300 threads run 10 个线程运行 5 分钟的基准测试，模拟多线程切换

ps aux | sort -k3nr |head -n 10 按照按照消耗CPU前10排序的进程

ps aux | sort -k4nr |head -n 10 按照按照消耗内存前10排序的进程

pstree -p | wc -l 查询当前整个系统已用的线程或进程数

pstree -p pid | wc -l 统计进程的线程数

ps -o nlwp pid 查看进程下的线程数

1：netstat -nat|grep ESTABLISHED|wc -l 查看系统的总连接数

2：netstat -anp|grep pid|wc -l 统计进程的总连接数

注：1和2组合使用

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 查看连接状态

watch -d -n 1 'cat /proc/softirqs' 查看中断种类。NET_TX 或 NET _RX 如果变化很快的话就是网络中断引起的，

否则是由系统其他原因造成的中断

ps -A -o stat,ppid,pid,cmd |grep -e '^[Zz]' 定位僵尸进程

kill -HUP 僵尸进程父ID 杀死僵尸进程

ps -eLo pid,stat | grep 3598 | grep running | wc -l 根据进程状态筛选线程

time dd if=/dev/zero of=test bs=1M count=4096 测试IO读写速度

sync;time -p bash -c "(dd if=/dev/zero of=test bs=1M count=200)" 当前目录下创建一个test的文件，写入200个1M的数据。测试写瓶颈

hdparm -tT --direct /dev/sda 测试读瓶颈

iozone -a -n 512k -g 4m -i 0 -i 1 -i 5 -f /mnt/iozone -Rb ./iozone.xls

https://www.jianshu.com/p/8fadfaa5abe6 io测试

wget [http://www.iozone.org/src/current/iozone3_482.tar](https://links.jianshu.com/go?to=http%3A%2F%2Fwww.iozone.org%2Fsrc%2Fcurrent%2Fiozone3_482.tar)

tar -xvf iozone3_429.tar

cd iozone3_429/src/current

apt-get install gcc

make

make linux-ia64

iostat -x -k -d 1

iotop -botq -p 【pid】 输出进程的io信息

iotop -d 2 -n 5 间隔2秒，输出5次 监控时间段内的IO

iotop -o 显示产生IO的进程

%iowait：不能反应磁盘瓶颈 实际反应的是cpu的io等待时间：%iowait = (cpu idle time)/(all cpu time)

rrqm/s: 每秒对该设备的读请求被合并次数，文件系统会对读取同块(block)的请求进行合并

wrqm/s: 每秒对该设备的写请求被合并次数

r/s: 每秒完成的读次数

w/s: 每秒完成的写次数

rkB/s: 每秒读数据量(kB 为单位)

wkB/s: 每秒写数据量(kB 为单位)

avgrq-sz:平均每次 IO 操作的数据量(扇区数为单位)

avgqu-sz: 是平均请求队列的长度。队列长度越短越好

await: 平均每次 IO 请求等待时间(包括等待时间和处理时间，毫秒为单位)。一般地系统IO响应时间应该低于5ms

svctm: 平均每次 IO 请求的处理时间(毫秒为单位)

%util: 1 秒中有百分之多少的时间用于 I/O 操作。该参数表示了设备的繁忙程度

CPU会拿出一部分时间来等待IO（iowait），从磁盘的角度看，如果磁盘的利用率已经满了（util%），这种情况下，CPU使用率可能不高，但是系统整体QPS已经上不去了，如果继续加大流量，会导致单次IO耗时的继续增加（IO请求都堵在队列里），从而影响系统整体的性能。

高iowait，并不代表磁盘的瓶颈。唯一能说明磁盘是系统瓶颈的方法是很高的svctm，一般来说超过20ms，就代表了不太正常的磁盘性能。只要大于20ms，就必须考虑是否磁盘读写的次数太多，导致磁盘性能降低。

svctm 一般要小于 await。svctm的大小一般和磁盘性能有关，CPU/内存的负荷也会对其有影响，请求过多也会导致 svctm 的增加。await 的大小一般取决于svctm 以及 I/O 队列的长度。如果 svctm 接近 await，说明 I/O 几乎没有等待时间；如果 await 远大于 svctm，说明I/O队列太长，应用的响应时间变慢，如果响应时间超过了用户可以容许的范围，需要考虑更换更快的磁盘；调整内核elevator 算法；优化应用；升级CPU

经验总结：

1：提高IO效率原则： 顺序写，随机读

2：重点监控 rkB/s 和 和 wkB/s

3：%util接近100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈

4：await与svctm相差很大的时候，要注意磁盘的IO性能。差值越小，说明队列时间越短，反之则队列时间越长。说明系统出了问题。

规避IO负载过高：

1. 如果服务器用来做日志分析，注意随机读和顺序写，避免定期的压缩、解压大日志。

2. 如果是前端应用服务器，要避免程序频繁打本地日志、或者异常日志

3. 如果是存储服务（mysql、nosql），尽量将服务部署在单独的节点上，做读写分离降低压力

超市排队去哪个柜台付款？

1：首先看排的队人数，5个人比20人要快

2：看前面人购买的东西多少，如果前面的人购买了一个月的物品，可以考虑换个队伍排

3：看收银员的速度，如果碰上了新手，那等待时间会很久

I/O 对比超市排队:
r/s+w/s 类似于排队的人员总数

平均队列长度(avgqu-sz)相当于单位时间里平均排队的人数

平均服务时间(svctm)相当于收银员的收款速度

平均等待时间(await)相当于平均每人的等待时间

平均I/O数据(avgrq-sz)相当于平均每人所买的东西多少

I/O 操作率 (%util)相当于收款台前有人排队的时间比例