性能测试常见问题

性能测试的概念及分类：

• 性能测试：首先要确定系统的业务模型，指定合理的测试方案和策略，通过自动化的工具模拟正常，异常，峰值等负载条件对系统的各项指标进行验证。
• 基准测试：系统无压力的情况下，选择一个接口模拟一些用户并发，持续执行一段时间获取该交易的响应时间，TPS，资源消耗等，主要的目的是完成验证工作，为其他的类型性能测试作为基准。
• 负载测试：负载测试是验证不同负载（或者不同并发）下系统的指标，发现可能存在的性能问题，检测系统的伸缩性，也可以验证在什么负载条件下系统性能处于失效状态。
• 混合测试：选取多个交易按比例混合，模拟一定数量的用户多次迭代，持续执行一段时间，获取个交易平均响应时间，TPS,服务器资源消耗等等。
• 稳定性测试：选取系统稳定运行情况下能够支持的并发数，持续运行一段时间，目标是检测系统能否持续稳定（如系统：7 * 24小时运行，测试应当系统在一定的压力情况下（如CPU使用率维持在60%）），选取混合场景的案例持续运行7 * 24小时运行，观察系统的文档性状态数据。
• 摸高测试：摸高测试也称梯度加压，是一种测试方法，同一个案例执行过程内通过不断增加并发，获取交易的平均响应时间，TPS,变化情况，找出系统最大并发的用户数和TPS的峰值。

性能指标：

并发用户数量概念：

• 同一时刻操作某个页面或者某个功能的用户数，描述系统能够承受的并发性能，它是一个时间段内发生的事情，它意在表达“并发”的可能性，是压力的一种度量。
• 响应时间：用户发起请求后到收到响应返回的时间，描述交易执行快慢的程度，计算规则：响应时间=系统响应时间+网络传输时间。Average:所有请求响应时间的平均值。Line95:95%的请求响应时间都在该值以下，line99:99%的请求响应时间都在该值以下。Minimum:所有请求中响应时间最低值。Max:所有请求中响应时间最高。
• TPS：指每秒处理事务数，TPS=总事务数/总时间，描述了服务器的处理能力。
  之间的关系：随着用户数量的不断增加：资源利用率达到饱和，：系统的TPS在并发用户达到顶点开始下降，系统的响应时间不断增加，图中第一条虚线为系统拐点，系统在拐点附近已达到处理极限，可作为扩容依据。

资源指标：

• CPU：物理核：真实的CPU核：有独立的电路元件及缓存（L1,L2），可以独立的执行命令
• 逻辑核：在同一个物理核内，逻辑层面的核。
• 超线程：（HT，Hyper-Threading）:使用特殊的硬件指令，把逻辑内核模拟成物理内核来实现多线程并行计算，提高并行效率，如果两个线程同时需要某个资源时，其中一个线程挂起，因此采用超线程之后的逻辑核能力是小于通等数量的物理核能力。
• 建议：申请性能环境一般要求单台配置和生产环境配置保持一致，因此心梗换进到位后建议确认一下内核数量和内核种类。（都未使用超线程，都使用了超线程）
• CPU使用率和Load：
  <0.70,可以认为LOAD较为正常
  ">=1.00 大于等于1，表示线程处于等待CPU的状态，需要尽快定位并解决，否则将导致应用程序变慢。
  “>=3.00 系统变得非常慢，甚至很难通过命令操作来找出问题，可能系统崩溃。
• 内存使用率：
  虚拟机内存使用率一般要求低于60%，total减去used并真正的可用内存，Availiable才是真正当前空闲内存，因为系统会把一部分内存分给缓存。容器的关注内存：workingset，要求内存使用率一般不低于60%
• IO：一般要求磁盘繁忙绿低于60%，对于数据库来说读写响应时间最好是：低于1ms
• 网络相关：网络一般和地理有关系，在同一个机房内要求RTT不超过1ms
• 带宽的计算：（上行+下行）* 8 =****
• GC:
  GCcount 代表JVM在一分钟内发生的GC次数，GCtime 代表JVM在一分钟内GC总耗时，如果在性能过程中出现FGC，需要开发介入。
• 慢SQL：慢SQL是执行速度较慢的SQL的查询语句，通常，当一个SQL查询的执行时间超过了合理的预期或者对系统性能差生了明显的影响时，就可以被称为慢SQL，一旦出现慢SQL可以要求开发进行分析，测试人员也可以通过explain+SQL 来分析SQL的执行计划定位问题。
• 数据库的连接数：
  通常指的是：与数据库服务器建立的活动链接的数量，不同的数据库系统有不同的方式来管理和查询当前的连接数。
  MAXconnections数据库最大连接数，Connection:当前连接数据，RUNNING，connection：活跃的连接数，注意观察：connections使用趋势，是否不断地增长，压测完成后是否释放。
• redis的慢日志（Slow log）是用于记录执行时间超过预期阀值的命令请求的系统，慢日志可以帮助运维人员和开发人员识别潜在的性能瓶颈，定位那些可能导致redis性能下降或响应延迟的慢查询。

常见问题的分析和诊断：

性能环境架构：

例如：
jmeter--------controller1,controller2------服务器：
相关配置： MYSQL 8.0，单机，4C8G，磁盘：200G

1.问题：

混合测试：性能测试混合场景-12min-梯度加压，8个用户加载完毕后，mysql数据库CPU使用率是100%

1.问题分析：

1.对于mysql错误日志，磁盘使用率，磁盘inode使用率，系统messages等信息进行确认，都未发现有相关异常！
2.进入容器：获取应用日志，发现SQL：
select id ,name ,empl_no,card_id,dept_name,sex,live_type,apply_type from ams_prh_waiting_list_info where um='测试5' and del_flag=0
3.执行计划：explain select
id ,name ,empl_no,card_id,dept_name,sex,live_type,apply_type from ams_prh_waiting_list_info where um='测试5' and del_flag=0
4.查看索引：
show index from ams_prh_waiting_list_info;
Table Non_unique key _name Seq_in_index Column_name_Collation cardinality Sub_part Packed Null Index_type Comment index_comment Visible Expression
arms_prh_wating_list_info O PRIMARY 1 id A 19681 NULL NULL BTREE YES
解释：
Non_unique 如果mysql 索引不包括重复词，则为0，否则则为1， key-name索引名称，Seq_in_index 索引序列，
5.创建索引：
create index_num_del_flag_index on arms_prh_waiting_list_info(del_flag);
create index_num_index on arms_prh_waiting_queue(num)

6.性能验证：CPU使用率30%，达标

问题2:OOM定位：

问题背景：

1.某关联图谱应用在性能测试过程中，一直出现：Metaspace 内存不够导致的OOM问题发生，导致系统崩溃而影响整个系统业务的连续性，因此必须在投产前解决OOM的问题。

2.链路如下：
jemeter1 and jemeter2 -----》F5-------》发欺诈应用1 ，反欺诈应用2，-------》orcale数据库
3.jvm参数：
-server-xms1024m-Xmx1024M-xx:MetaspaceSize=128m -XX:MaxMetaspaceSize=128M-XX:SurvivoRatio=8-XX:+UseComcMarkSweepGC -XX:+UseCMSInitiaatingOccupancyOnly-XX:CMCSInitiatingOccupancFraction=70-XX:ParallelGCThreads =10 -XX:+UseFastAccessorMethods -XX:+UseCompressedOoops-XX:+CMSParallelRemarkEnabled -xx:DisableExplicitGC -XX:+UseAdaptiveSizePolicy
4.首先要了解Metaspace的基本概念，里面存放了哪些东西，MetaSpace是JDK1.8引入的，在JDK1.89之前使用的是方法区，永久代（Pernament Generation）,JDK1.8引用的是元空间，元空间存储的是元信息，使用的是操作系统的本地内存，可以是不连续的，由于空间虚拟机进行管理，可以产生OutOfMemoryError;
MetaSpace用于存放虚拟机加载的类信息，常量，静态变量和即时编译后的代码等等。
5.第一部查看：MetaSpace区域的class信息，
ps -ef|grep java 获取PID
jmap -clstates PID >cl.log
vi cl.log
生成cl.log 文件后使用less cl.log 例如：基本全是反射类加载器，由此可初步定位，MetaSpace OOM是由于DelegatingClassLoader（举例）加载器过多次导致的，加载器是有哪些类造成的呢，需要继续排查：
6.在：start.sh文件的启动命令中加入-verybose:class 后再启动应用：
GRAPH_JVM_ARGS="-server -Xms1028m -Xmx1028m -versboss:class"....
7.重新启动应用.sh脚本，观察日志：
com.pab.graph.server.afds.controller.EnterpriseAndindividualController#getEnterpriseAndindividual 时会出现 sun.reflect.GenerateMethodAccessor加载进Metaspace
7.进入代码层面观察：etEnterpriseAndindividual ，
8.定位到具体语句：
如下代码没查询一次 JSONObject.parseObject(sourceAsString),idvAndEntpRelaVo.class),使用反射把json转化为Java对象
9：方案一：改写反射代码
方案二：在JVM启动中加入：-Dsun.reflect.inflationThreashold=0.不建议是用回降低性能。

问题3：高并发偶发异常排查记录：

• 业务场景：
  先调用A接口，查询订单号，根据接口A返回调用B接口，查询对饮的订单详情
  具体现象：在性能测试管理平台执行时，有少量的报错，Error%为3%；
• 日志追踪：
  通过平台压力机断言日志，追踪问题点，从日志可知：事物控制器请求null，下一步需要检查脚本，查看脚本中“事物控制”是否合理。
• 将脚本下载到本地，检查事物控制器，发现勾选了事物控制器的Generate parent Sample,导致食物中某个接口执行报错时只显示事务控制器报错。
  注意：添加事务控制默认是勾选：Generate paren Sample，
• 取消Generate paren Sample ，重新跑数据可以看到具体的错误信息：
• 根据运行结果A接口返回的订单号应该是存在，查询客户数据成功，sessionTick也是有数据逇，如下图所示，原因通过日志查看查询失败的时候接口入参订单列表字段传值为null，判断应该是应用高并发是程序偶发处理异常，反馈给开发进行代码排查，最终发现是应用代码中工具类全局变量的问题。

总结：

1. • 脚本编写中涉及到多个接口传递时候：不要勾选Generate parent Sample，既方便实际反应应用处理的请求数，也方便问题排查。
2. 脚本编写涉及多个接口无值关联的时候，勾选Generate parent Sample，将多个接口当做一个有效的事物进行计算。
3. 代码中涉及到全局变量的时候，比较容易出现高并发时取值的问题，代码中全局变量谨慎使用，
4. 业务代码中反射的要注意，以防有null值导致业务异常。
5. 对于性能测试中偶发报错，需要深入分析，不能够放过，否则性能测试会变形。