性能测试常见问题分析

性能测试常见问题分析

1. 请你个人描述一下性能测试的意义和作用，说出因性能不良造成的质量事故？
2. 如何进行性能测试，请说出整体的性能测试流程？
a）分析测试范围，测试对象（如频繁使用的功能、频繁调用的接口，大量数据库读写操作多的功能、大量读写系统缓存的功能）；
b）根据历史性能数据，或者用户的性能需求，制定测试计划，测试策略，测试方法；
c）准备测试环境（环境要干净，且尽可能与生产保存一致）；
d）准备测试脚本(录制、参数化、关联等配置)；
e）设计测试场景，并根据场景设置，执行测试脚本（如某个时间点做某一个业务的用户特别多）；
f）分析测试结果：首先看系统日志（异常原因可能有服务器异常、数据库异常、代码异常、网络异常等等）；
g）给出优化建议。

3. 你觉得性能测试的难点在哪里？如何克服？
答：见仁见智
a）测试计划，策略的制定，测试场景的设计；
b）性能结果的分析及性能调优。

4. 如何选择性能测试工具？

5. 如何确定性能测试团队的人力资源需求？

6. 作为一个新手，你觉得性能测试会用到哪些知识？
a）工具的使用能力；
b）网络协议等知识；
c）编码能力；
d）数据库的知识，配置、调优等。
e）中间件的知识；

7. 你曾经遇到的性能测试挑战是什么？如何克服的？

8. 你觉得性能测试工程师如果分为三个级别，你如何来划分这三个级别的能力要求？

9. 如何分析一个系统的瓶颈？你常见的性能瓶颈请列举5-10条，并说出解决方案？
答：分析系统瓶颈最笨的方法是按业务规则去压并发；
常见性能瓶颈总结如下：
参考：https://www.cnblogs.com/imyalost/p/10850811.html
a）TPS上下抖动，即波动较大(呈锯齿状)
原因一般有：网络波动、其他服务资源竞争以及垃圾回收问题这三种
性能测试环境一般都是在内网或者压测机和服务在同一网段，可通过监控网络的出入流量来排查；
其他服务资源竞争也可能造成这一问题，可以通过Top命令或服务梳理方式来排查在压测时是否有其他服务运行导致资源竞争；
垃圾回收问题相对来说是最常见的导致TPS波动的一种原因，可以通过GC监控命令来排查，命令如下：

# 实时打印到屏幕
jstat -gc PID 300 10
jstat -gcutil PID 300 10
# GC信息输出到文件
jstat -gc PID 1000 120 >>/path/gc.txt
jstat -gcutil PID 1000 120 >>/path/gc.txt

调优方案：
网络波动问题，可以让运维同事协助解决（比如切换网段或选择内网压测），或者等到网络较为稳定时候进行压测验证；
资源竞争问题：通过命令监控和服务梳理，找出压测时正在运行的其他服务，通过沟通协调停止该服务（或者换个没资源竞争的服务节点重新压测也可以）；
垃圾回收问题：通过GC文件分析，如果发现有频繁的FGC，可以通过修改JVM的堆内存参数Xmx，然后再次压测验证（Xmx最大值不要超过服务节点内存的50%！）
PS：这里我想再补充一个可能的原因，压力机给的压力不稳定，也会造成TPS抖动。
之前有朋友遇到，在JMETER2.8版本上使用CSV Data Set Config做了参数化，当切换为2.13版本后，
沿用旧脚本时，就算性能测试场景中没有使用到该参数，也导致了TPS抖动，在禁用并新建了一个CSV Data Set Config，
问题得到了解决，所以推测是老版本的CSV Data Set Config在新版本的JMeter压测时，
调度存在问题，导致给服务器的压力不稳定。

b）高并发下大量报错
原因解析：出现该类问题，常见的原因有短连接导致的端口被完全占用以及线程池最大线程数配置较小及超时时间较短导致。
调优方案：
短连接问题：修改服务节点的tcp_tw_reuse参数为1，释放TIME_WAIT scoket用于新的连接；
线程池问题：修改服务节点中容器的server.xml文件中的配置参数，主要修改如下几个参数：

# 最大线程数，即服务端可以同时响应处理的最大请求数
maxThreads="200"                        
# Tomcat的最大连接线程数，即超过设定的阈值，Tomcat会关闭不再需要的socket线程       
maxSpareThreads="200"               
# 所有可用线程耗尽时，可放在请求等待队列中的请求数，超过该阈值的请求将不予处理，返回Connection refused错误
acceptCount="200"                 
# 等待超时的阈值，单位为毫秒，设置为0时表示永不超时
connectionTimeout="20000"

c）集群类系统，各服务节点负载不均衡
原因解析：出现这类问题的原因一般是SLB(负载均衡服务器)服务设置了会话保持，会导致请求只分发到其中一个节点。
调优方案：如果确认是如上原因，可通过修改SLB服务（F5/HA/Nginx）的会话保持参数为None，然后再次压测验证；
d）并发数不断增加，TPS上不去，CPU使用率较低

原因解析：出现该类问题，常见的原因有：SQL没有创建索引/SQL语句筛选条件不明确、代码中设有同步锁，高并发时出现锁等待；
调优方案：

SQL问题：没有索引就创建索引，SQL语句筛选条件不明确就优化SQL和业务逻辑；

同步锁问题：是否去掉同步锁，有时候不仅仅是技术问题，还涉及到业务逻辑的各种判断，是否去掉同步锁，建议和开发产品同事沟通确认；
e）压测过程中TPS不断下降，CPU使用率不断降低

原因解析：一般来说，出现这种问题的原因是因为线程block导致，当然不排除其他可能；

调优方案：如果是线程阻塞问题，修改线程策略，然后重新验证即可；

• 如何分析一个linux系统存在了内存不足？

• 如何证明一个linux系统中的程序存在内存泄露？

• 如何证明一个linux系统中的IO能力存在瓶颈？

• Loadrunner 中的UNIQUE会使用在哪种性能测试场景需求中使用？

• 请说出Loadrunner的关联是怎么回事？

• 性能测试和压力测试是个什么关系？
答：压力测试是性能测试的一部分。

• 压力测试与负载测试的关系：
答：
a）负载测试的目的是找出系统的极限（能承受多大的并发，能承受多少数据）
负载测试是逐步增加系统的负载，测试系统性能的变化，
确定满足性能指标的前提下，系统所能承受的最大负载量。
负载测试属于极限测试。

b）压力测试的目的是找出系统在什么时候会崩溃，
压力测试也是逐步增加系统的负载，测试系统性能的变化，
最终确定在什么情况下，系统性能属于失效、崩溃、跑不动状态。
压力测试属于破坏测试。

• Loadrunner的脚本出现乱码如何解决？
答：可以采用看日志，确定乱码的位置
一般字符集设置为utf-8格式，基本可以解决。

• Loadrunner的录制脚本时候浏览器始终无法打开，你会如何解决？

• 录制脚本的2个模式分别是什么？他们的区别？

• Loadrunner的随机化用在什么场景？

• 如果loadrunner的脚本运行中报错，你会如何分析原因和解决？
答：看日志
• 如果让你自己写个性能测试的程序，你能讲讲实现原理或者初步的实现想法么？

• 如何制定一个性能测试的指标？哪些指标是核心的？
答：核心指标：TPS、响应时间、吞吐率、点击率，CPU占用率，磁盘占用率，内存占用率。
最最核心：TPS、响应时间
• 请问线程和进程有什么区别？
a）进程是程序的一次执行，是资源分配的最小地址；
b）线程是进程中调度的最小单位
c）进程有独立的内存空间，线程没有独立的内存空间，它必须运行在进程中；
d）线程之间通信更方便，因为同一进程下的所有线程，共用资源该进程的资源，
包括全局变量、静态变量等数据；
而进程之间的通信需要以IPC的方式进行通信。对于多线程解决同步与互斥是难点。
e）多进程的程序更健壮，多线程程序只要有一个线程死掉，整个进程也死掉了，
而一个进程死掉并不会对另外一个进程造成影响，因为进程有自己独立的地址空间
• 请问Loadrunner的并发数和在线用户数是个什么关系？请说出你的理解？

• 你觉得系统性能如果出现瓶颈，那么分析和调优应该是谁来负责？

• 请说出你见过的一些设计优秀的网站系统框架，并且说明他们的优点和缺点？

• 如何找到大型系统中的最大瓶颈点？

• 如果你怀疑某段程序有问题，你如何来证明程序的性能好坏？
答：
a）看是否有error message;
b）可以在脚本中，将该程序设为一个事务进行测试；
c）看该程序所在文件的大小，文件越大资源可能就越大。
程序所在的文件，应该越小越好。