如何面试性能测试

原文地址：https://www.cnblogs.com/UncleYong/p/10641248.html

最近，在一些群里经常看到有测试朋友在问有没有性能测试面试的资料，

因为自己也一直在做性能测试，所以就做个总结分享给大家吧（可能你看了会懵逼，你可以点击左侧加群来聊聊）。

但是，做性能需要掌握的知识面很宽泛（linux、数据库、各种中间件的基本配置调优等等），而且还需要一定的深度，这样才能去做性能分析、定位，所以大家一定要坚持学习。

一般来说，面试性能，围绕以下几个方面去说就可以了：

性能测试流程

1.性能需求分析

　　基于接口或者场景（全链路）的性能测试指标，一般是tps（每秒事务数，这里都是通过的事务）及art（平均响应时间）

2.了解系统架构，申请性能测试环境

　　用到的web服务器、应用服务器、缓存数据库服务器、数据库服务器等

3.制定性能测试方案

4.搭建测试环境，准备测试数据

　　性能测试，数据库的存量数据，比如一个查询接口，都是并发100用户，对应的表数据量是1万和100万，压测结果是不一样的，这个数据量根据生产环境获取

5.主流程稳定后，开发压测脚本

　　参数化、关联、事务、思考时间、断言等

6.预压测

　　少量并发（比如1个用户），看压测环境功能是否通

7.执行压测并监控服务器资源情况

　　看测试指标是否满足需求及服务器资源（cpu、内存、磁盘io、网络）是否存在瓶颈

8.分析定位

　　从请求开始，一步一步排查请求流经的节点

9.优化，性能回归

10.性能报告 

性能测试常见问题

性能测试结果中，我们关注的指标是tps和art，如果tps低，或者响应时间长，那就需要我们去定位性能问题了，

常见的性能问题主要包含：

　　a.客户端问题，比如压力机服务器资源不足，请求发不出去

cpu：top/vmstat

内存：free -m

磁盘io：iostat -x -k 1

　　b.网络带宽，通过nmon或者sar定位；看有没有丢包

　　c.应用服务器load高：top、jstack等

　　d.oom：fgc频繁，jstat -gcutil

　　e.等待io：看io有没有排队

　　f.web容器排队，连接池问题（不足或者没释放）

　　g.数据库连接池排队，连接池问题（不足或者没释放）

　　h.慢查询

　　i.数据库死锁

　　j.线程死锁：jstack

　　k.代码业务逻辑

性能测试问题定位举例

最近的性能测试中，遇到一个数据库连接池不释放的问题，下面描述下定位到这个问题的流程。

我们用的是dubbo框架

1.首先，压测过程中，请求失败了，所以，赶紧去看provider服务器日志（tail -f -n500 xxx.log），抛出的错误是：

2.原来是没获取到数据库的连接池，马上去看了下配置文件（less db.properties，最大连接数配置的100，此时并发的150），首先想到的是连接数配置的小了，于是改为150，当然，这个需要比数据库自身允许的连接数小，显示数据库最大连接数：select value from v$parameter where name ='processes'; 

重启服务，初始化数据库中的数据

注意：实，连接数并不是一定要比并发数大，因为由于漏斗原理，哪怕并发150，实际到数据库的并发可能只有几十

3.重新压测，过了一会儿，还是报相同的错，此时我并发的150，于是，怀疑要么是有其他人也在用我的数据库服务器，要么就是数据库连接池没释放

4.马上连接到consumer服务器，首先看有没非我压力机的ip

netstat -an | grep 72.32.3.141:8080 | awk '{print $5}' | awk -F ':' '{print $4}' | sort | uniq -c | sort -nr

结果只有我压力机的ip，排除其它人在用我的服务器，所以很可能就是数据库连接池没有释放了

5.停止压测，过了一段时间，查数据库的连接数

显示数据库当前的连接数：select count(*) from v$process; 

结果是150+，连接池被占满了

6.再次修改连接池，改为200，重新压测，依旧报相同的错，查数据库的连接数，连接池也被占满了

7.过了一段时间再查，连接池依旧是被占满的状态，至此，可以断定，是数据库连接池未释放。

这个性能问题相对简单，因为错误日志已经为我们指明了大致的方向。