当前位置：首页 > news >正文

3.31-4 性能面试题

news 来源：原创 2025/7/2 18:24:19

面试题

1、性能问题的六个特征：

（1）、持续缓慢：

（2）、随着时间推进越来越慢、

（3）、随着负载增加越来越慢、

（4）、零星挂起或异常错误、

（5）、可预见的锁定、

（6）、突然混乱、

2、性能瓶颈

性能瓶颈定义：导致系统TPS低、响应时间长、资源（CPU、内存、网络）占用高等问题的

（1）、找到性能瓶颈

瓶颈的类型：

a、网络瓶颈，如带宽，流量等形成的网络环境

b、应用服务瓶颈，如中间件的基本配置，CACHE等

c、系统瓶颈，这个比较常用：应用服务器，数据库服务器以及客户机的CPU，内存，硬盘等配置

d、数据库瓶颈，以ORACLE为例，SYS中默认的一些参数设置

e、应用程序本身瓶颈，

关键程序模块。提升该程序模块的性能，可以大幅度改善性能。

常见的性能瓶颈原因包括：数据库慢查询SQL、日志打印、xml大报文解析和格式转换、复杂业务逻辑、锁竞争等。

（2）、如何找到性能瓶颈

使用jmeter或LoadRunner给每个接口的增加事务，记录其响应时间和TPS，最慢的那个接口往往是瓶颈；

分析慢交易的日志，查看是哪个操作耗时最长；

分析数据库快照，看是否有执行较慢或者全表扫描的SQL；

通过Javacore查看线程正在执行的代码，是大部分阻塞在IO上，还是大部分在进行计算。针对不同的问题，使用不同的分析工具。详细内容可以看下一章节。

（3）、针对性能瓶颈进行合理优化

性能优化原则：

先优化瓶颈问题；

方案简单，尽量不引入更多复杂性，尽量不降低业务体验；

满足系统性能要求即可，不引入新的bug。

3、如何定位性能问题？

A. 查看系统日志，日志是定位问题的不二法宝，如果日志记录的全面，很容易通过日志发现问题。

比如，系统宕机时，系统日志打印了某方法执行时抛出out of memory的错误，我们就可以顺藤摸瓜，很快定位到导致内存溢出的问题在哪里。

B. 利用性能监控工具，比如：JAVA开发B/S结构的项目，可以通过JDK自带的Jconsole，或者JProfiler，来监控服务器性能，Jconsole可以远程监控服务器的CPU，内存，线程等状态，并绘制变化曲线图。

利用Spotlight可以监控数据库使用情况。

我们需要关注的性能点有：CPU负载，内存使用率，网络I/O等

C. 工具和日志只是手段，除此之外，还需要设计合理的性能测试场景

具体场景有：性能测试，负载测试，压力测试，稳定性测试，浪涌测试等

好的测试场景，能更加快速的发现瓶颈，定位瓶颈

D. 了解系统参数配置，可以进行后期的性能调优

4、简要说明性能测试流程？

（1） .分析性能需求。选择用户最常用的场景进行测试，例如登录、搜索和订购。确定绩效指标。例如，事务通过率为100%，TOP99%为5秒，最多同时用户1000人，CPU和内存使用率低于70%。

（2）制定性能测试计划，明确测试时间(一般在功能稳定后，如第一次测试后进行)、测试环境和测试工具

（3）编写新能测试用例

（4）建立性能测试环境，准备性能测试数据

（5）编写性能测试脚本

（6）性能测试脚本优化。设置检查点、参数化、关联、聚合点、事务，调整思考时间，删除冗长的脚本

（7）设计测试场景，运行测试脚本，监控服务器，

（8）分析测试结果，收集并开发相关日志提单

（9）回归性能测试

（10）写测试报告

（11）性能调优

5、如何确定系统的最大负载？

通过负载测试，增加用户数量。随着用户数量的增加，各项性能指标也相应变化。当性能拐点出现时，例如，当用户达到某个订单时，如果响应时间突然增加，则该拐点的对应用户数可以是该系统可以装载的最大用户数。

6、你的系统哪里(哪些功能)进行了性能测试？

我们选择了用户最常用的功能进行了测试，包括登录、搜索和提交订单

7、你们的同时用户数是怎么确定的？

1 )上线一段时间，根据收集到的用户访问数据进行估计

2 )根据需求决定(高峰时间段、注册用户数、1次响应时间等

8、你们的性能测试在什么环境下进行？

独立的性能测试环境进行测试

9、你们的性能测试什么时候进行？

基准测试：功能测试后，在系统稳定时进行。

负载测试：夜深，系统无人使用时

10、如何分析性能测试结果？

首先看事物的通过率，然后分析其他性能指标。例如，如果测试结果不可靠，如响应时间、事务通过率、CPU等指标是否满足需求，请分析并纠正异常原因，然后重新测试

11、如何识别系统瓶颈？

通过TPS指标分析，TPS是在系统单位时间内处理的事务数量。观察当前随着用户数量的增加，系统每秒能处理的事务数是否也会增加

12、如何判断系统性能是变好了还是变坏了？

通过基准比较性能指标。

13、你们的性能测试需求来自哪里？

(1) :客户提供需求(主要)

(2 )运维需求

(3 )开发提供需求

14.

具有验证码功能。你怎么做性能测试？

1 )临时屏蔽验证码，完成性能测试后恢复

2 )使用万能的验证码

15.如何加强性能脚本？

如何加强脚本？

1 )参数化

2 )相关

3 )添加事务

4 )添加断言

5 )增加集合点

6 )增加思考时间

案例1

性能测试压测50怎么做的？

案例1：在工作中我测试会对单个接口进行压测或一个性能场景进行压测；首先会分析需求，根据需求分析接口和场景做性能；设计性能场景；根据性能场景使用badboy（或反向代理录制脚本）录制脚本；将录制的脚本进行参数化、并且调通；在测试计划中设置压测用户数，设置压测时间，在添加查看结果树、聚合报告、tps插件、hps插件、混合图标、图像报告、表单报告等插件，在服务器中也可以使用nmon来采集硬件指标：cpu、内存、硬盘、网络I/等，或top命令去监控，在点击执行；然后就能检测到性能参数；在收集的实际性能指标进行分析和预期指标进行对比。对比后分析性能问题，给出性能报告；最后在进行性能调优。

案例2:

性能测试或者压力测试你是怎么做的？

我们产品经理首先会评审性能需求，产品经理把需求分析过后，我们就根据需求做性能场景的设计，比如我就拿

这样的一个场景，和您这边大概说一下：

首先我会设计好这个性能测试用例之后，然后接着在Jmeter里面开始组建接口，把接口请求组建好之后，然后再添加吞吐量定时器，再添加TPS插件，HPS插件，以及混合图表，查看结果树，聚合报告，以及对应的一个并发线程数比如50，然后选择压测10分钟，然后就开始点击运行，进行压测，在压测过程当中，我一般会通过混合图表去看当负载不断升高的时候，也就是我的并发线程数，它负载升高的时候我的接口的响应时间跟我的TPS之间的一个曲线变化，当我的TPS到达最高点，响应时间开始急剧上升的时候，这个时候一般就会出现一些捌点或瓶颈点，那我们去看一下它后续的一个曲线变化是怎么样的，后续如果TPS没有很快的急剧上升而是平缓的运行，我们这个时候就会去看它的、监控它的TPS是否符合我们原来设定的那个TPS、因为之前我们计算得出来的TPS需要高于105笔/秒，但我压的时候平均都能达到300多TPS，TPS这块就是符合需求的，但是只关注这个标指标还不行，还需要关注这个接口它的平均响应时间是不是在3秒钟之内。0到1秒一般是比较优秀，说明这个接口响应时间必较快速，1到3秒合格，超过了3秒我这边就会调整并发或者rps并且重新去压，还有就是错误率。我们之前的错误率指标需要低于0.1%，如果错误大于了0.1%此时说明接口有很多的报错，也是不符合性能要求的，直到我们压完之后如果TPS达标，接口平均响应时间达标，错误率达标之后。我们还需要在服务器端用top和iostat和dstat命令去监控它的cpu和内存，如果CPU和内存的使用率都能低于70%的话那就说明没问题，我会去输出性能测试报告，然后再发送报告给到我整个项目组

相关文章：