l_q_l的专栏

在性能测试过程中，需求分析以及性能指标的确定，是性能测试方案中的重要部分。通过分析系统，抽取测试场景，分析业务性能指标，最终确定测试模型。通常，系统核心业务/模块，产品或需求人员都能比较清晰地梳理出来，但是，每个场景的性能指标，不一定是清晰的。那么，如何确定所抽取场景的性能指标呢？

1、首先排除压力机自身的问题，如CPU、内存，网络，脚本编写等2、监控中间件的访问日志，观察响应时间，大体确定耗时处于哪一段3、排查网络问题，监控压力机到后端服务器的网络，以及各服务器间的网络，是否达到网络上限4、监控服务端所有机器的操作系统负载，如CPU、内存、磁盘、网络是否达到瓶颈5、监控应用服务器的日志，查看是否存在ERROR日志，比如TimeOut或其他类型报错6、监控各中间件的连接数，如nginx、tomcat、mysql等，是否达到上限。

1、网络问题，尤其是走公网2、硬件资源：CPU、内存、磁盘3、数据库，慢SQL4、线程阻塞5、数据库6、程序问题7、第三方系统接口比较慢8、连接数问题逐项排查。

Tomcat 处理请求时，是需要 Connector 进行调度和控制的，Connector是Tomcat 处理请求的主干。Connector 中有一个 accepf队列,当客户端向服务器发送http请求时，如果客户端与操作系统完成三次握手建立了连接，就将该连接放入accept队列，poller从队列中获取到链接后，从链接中获取请求，生成一个java request，然后从 tomcat 内部的线程池中找到空闲的线程去执行对应请求。

数据库连接是应用程序与数据库之间的通信通道，通常指TCP连接。操作系统是通过个四元组来标识一个 TCP 链接:{本地ip，本地 port，远程 ip，远程 port}，这四个要素唯一确定一个 TCP 链接，任意一个要素不相同，就认为是一个不同的链接。在 Linux 系统中，一切皆文件，每一个TCP 链接都要占用一个文件句柄,系统允许创建的链接数取决于句柄数的上限。超过这个值再创建链接就会报这样的错误'Can't open so many files'

压测过程中，发现应用服务器的CPU使用率比较高(>80%)，有两种情况1、接口的性能非常好，比如响应时间<10ms，tps很高，此时CPU使用率高是正常的，不需要优化2、接口性能不好，比如响应时间>200ms，tps很低，此时需要考虑优化。

二、具体实施步骤1. 部署Oracle Exporter推荐使用以下两种Exporter之一：选项B：prometheus-oracle-exporter2. 配置Prometheus抓取在prometheus.yml中添加配置：3. 关键监控指标以下是与死锁相关的重要指标：推荐使用以下两种仪表板之一：导入方法：自定义死锁监控面板示例：5. 告警规则配置在Prometheus中添加告警规则：三、高级监控方案1. 自定义SQL监控通过orac

线程死锁是指 在执行过程中，因争夺共享资源​而陷入无限等待的状态，导致所有相关线程都无法继续执行。有两个线程，一个线程锁住了资源A，又想去锁定资源B，另外一个线程锁定了资源B又想去锁定资源A，两个线程都想去得到对方的资源，而又不愿释放自己的资源从而造成一种互相等待，无法执行的情况。

Linux 的 ​。

新建:new运行:runnable等待:waitting(无限期等待),timed waitting(限期等待）阻塞:blocked结束:terminated。

除了有图形化界面的visualVM之外，还可以通过命令行工具来监控JVM。

因为堆占用内存空间最大，堆也是Java垃圾回收的主要区域（重点对象），因此也称作“GC堆”（Garbage Collected Heap）1.各线程共享，主方法区要存放类信息、常量、静态变量（static），如:public static int a=10。：堆内存中存在大量对象，且都在被引用，无法被清理，导致堆内存不足，无法分配新对象。栈区比较小，所以只是存放对象的地址，对象的真正的的数据存放在堆区中。垃圾收集器是内存回收算法的具体实现，没有完美的收集器。（如未关闭的集合、缓存）。

是一个开源的（Web 服务器 + Servlet/JSP 引擎），主要用于部署和运行（如基于 Spring、Struts、JSP 等的应用）。：作为 Web 服务器，接收并响应 HTTP(S) 请求。：解析并运行 Java Servlet 和 JSP 页面。：通过线程池处理并发请求，提高性能。：支持 HTTP Session 管理（如用户登录状态）。：如 NIO、APR 等模式，优化网络 I/O 性能。

Cpu(id)的计算基准：所有核心的平均空闲时间。进程%CPU的计算基准：所有核心的总占用时间。多核系统中，进程的%CPU可超过总体使用率的平均值，因为前者是总和，后者是平均。这是正常现象，不表示统计错误。内存CPU使用率:<80%内存使用率:<80%磁盘繁忙度:<90%网络流量:<网络上限。

缓存穿透是指在使用redis时，数据在redis和数据库中都不存在，导致每次查询都要访问数据库，但是又不能把数据缓存到redis，从而后续每次请求都要查数据库，造成数据库压力过大，系统性能降低，甚至可能引起数据库宕机。一个热门的、经常被访问的数据过期或失效后，后续大量并发请求同时请求失效的数据直接访问数据库，导致数据库负载剧增，造成系统性能下降甚至崩溃的情况。2、空结果缓存：如果查询的数据不存在，也将结果缓存到缓存中，但设置一个较短的过期时间，避免频繁查询不存在的数据。

web系统通常包含客户端（浏览器）和服务端。：用户在浏览器地址栏中输入网址或点击链接，浏览器向服务器发送请求，请求页面的HTML、CSS、JavaScript、图片等静态资源。服务器接收到请求后，会将所需的资源文件发送给浏览器，浏览器开始下载资源文件。：浏览器收到HTML文件后，开始解析HTML代码，构建DOM树（文档对象模型）。：浏览器解析HTML时，会遇到链接的CSS和JavaScript文件，在解析过程中加载并执行这些文件，同时构建CSSOM树。

1、测试系统最大处理能力寻找系统最大的TPS，判断TPS和对应的响应时间是否满足预期。估算对业务量的处理能力。2、测试系统支持最高并发寻找系统最高能支持多少并发，当系统出现宕机、进程崩溃、报错率持续上升、响应时间超过可忍受范围（高频接口：<100ms，低频接口：<200ms）、程序无响应等情况，即可认为系统达到了可支持的最高并发。

集合点是为了增加瞬间并发压力的一种机制，在脚本中增加一个标记，所有虚拟用户执行到标记处会进行等待，等所有用户都到达后，再同时继续执行下一步操作。主要目的是**模拟瞬时高并发场景**，验证系统在突发流量下的处理能力。: 对服务器来说，会产生一种瞬间高并发: 对服务器来说，平均压力会降低。

如果包含混合场景，需要确定各接口/场景的业务比例示例：其中，TPS和响应时间都是指系统性能（吞吐量/TPS）到达拐点时的TPS和响应时间。业务占比：要保证做不同事务的用户满足比例关系。

将所有请求的响应时间先从大到小进行排序，计算指定比例的请求都是小于某个时间。该指标统计的是大多数请求的耗时。

使用数据库的 Exporter 采集慢查询指标。配置 Prometheus 采集 Exporter 数据。定义慢查询的阈值并设置告警规则。在 Grafana 中可视化慢查询指标。结合日志分析具体的慢查询语句。通过以上方法，可以全面监控和分析数据库的慢查询，及时发现和解决性能问题。3、定位慢查询的原因根据分析结果，定位慢查询的根本原因。​缺少索引：查询条件中的列没有索引，导致全表扫描。​低效的查询逻辑：如复杂的 JOIN、子查询或 GROUP BY。​锁争用：查询因等待锁而变慢。

MySQL：使用和INNODB_TRX表。​PostgreSQL：使用pg_locks和视图。​SQL Server：使用和动态管理视图。​Oracle：使用v$session视图。​MongoDB：使用命令。​Redis：使用INFO命令。