软考-第8个小时

交易处理指标 8 条逐条解释（秒杀下单事务例子）

（1）平均事务响应时间 所有下单事务，从发起到收到返回结果，耗时的平均值。例：1000 次下单，有的 0.1s、有的 0.3s，算出来平均 0.2s。 ⚠️缺点：平均值会掩盖慢请求，所以才有后面的百分比、分布。

（2）每秒事务数（TPS） 每秒成功完成的事务数量，也就是吞吐量，性能最核心指标。例：TPS=500，代表系统每秒可以成功处理 500 笔下单。

（3）每秒事务总数 和 TPS 容易混淆： TPS 一般只统计成功的事务；每秒事务总数 = 每秒成功事务 + 失败事务。用来看总请求涌入量，看报错占比。

（4）事务摘要 汇总清单：一共跑了多少事务、成功多少、失败多少、失败率。就是一张简单汇总表。

（5）事务性能摘要 摘要 + 基础耗时：总事务数、成功失败数、最大响应时间、最小响应时间、平均响应时间。比上面的摘要多了耗时信息。

（6）事务响应时间（负载下） 随着并发负载变化的响应时间曲线 比如：并发 200 人时平均 0.1s，并发 1000 人时平均 0.4s。看：用户变多之后，响应时间会不会急剧拉长。

（7）事务响应时间（百分比，也就是 90%/95%/99% 响应时间，必考！） 95% 响应时间：95% 的事务，耗时都小于这个值。例：95% 响应时间 0.25s，意思：100 笔下单里面，95 笔都在 0.25 秒以内完成，只有 5 笔更慢。 👉 考试重点：这个比平均值更有参考价值，不会被少数快请求 “掩盖掉慢的坏情况”。

（8）事务响应时间（分布） 直方图：统计耗时落在各个区间的事务数量。例：0~0.1s：600 笔；0.1~0.2s：300 笔；>0.2s：100 笔。

极简背诵区分

并发用户数指标：多少人同时压
交易处理指标：这些人下单之后，系统处理交易的统计

平均响应：所有耗时取平均数
每秒事务数 TPS：每秒成功交易量（吞吐量）
百分比响应时间：95% 这类，软考性能大题高频
响应时间分布：直方图，看慢请求分布

3、Web 请求指标（大白话解释，适配软考软件测评师）

这一组，是用户发出去的 HTTP 请求层面的统计，是 LoadRunner 里经典的指标

每秒点击次数（Hits per second） 每秒用户点击发起请求的次数。点一下页面、点按钮都会产生一次点击。注意：一次页面加载会产生很多次点击（图片、js、css 都算），不等于页面数。
点击次数摘要 整个测试过程里，所有点击的汇总：总点击、最大、最小、平均值。
吞吐量（Throughput） 每秒服务器发回来的数据量，单位一般是字节 / 秒。代表服务器往外输出流量快慢。吞吐越高，网络、服务器传输压力越大。
吞吐量摘要 整个测试的总吞吐量、平均、峰值。
HTTP 状态代码摘要 统计各种返回码：200 成功、404 找不到、500 服务器报错、302 跳转等，一眼看请求失败多不多。
每秒 HTTP 响应数 每秒服务器返回 HTTP 应答的数量。和点击数很接近，但是区分：发请求 = 点击，收到回复 = 响应。网络差的时候响应会滞后。
每秒下载页面数（Pages per second） 每秒完整加载好的页面数量。划重点：一个页面里面包含很多图片、css，所以页面数＜点击数。这个更贴近 “用户看完一页”。
每秒重试次数 每秒请求失败之后，客户端重新发请求的次数。重试多代表网络不稳、服务器丢包。
重试次数摘要 整个测试全部重试的汇总统计。
连接数 当前服务器和用户建立的 TCP 连接总数。长连接场景这个指标很关键。
每秒连接数 每秒新建 TCP 连接的数量，短连接场景压力大的时候这个数值会飙升。
每秒 SSL 连接数 HTTPS 的加密握手连接，每秒新建 SSL 连接。SSL 握手很耗 CPU，这个指标高，容易把服务器 CPU 打满。

4、Web 页面组件指标

这个是把一个网页拆开看：网页不是一块，是由 HTML、图片、js、css 这些一个个组件拼起来的，用来定位到底哪个资源加载慢。

激活网页细分 把每一个页面的耗时拆开：DNS、连接、SSL、发送请求、服务器处理、接收数据，看页面慢在哪一段。
页面组件细分 把页面里面每一个组件（每一张图、每一个 js 文件）单独统计耗时。比如是 logo 图片加载慢，还是接口 js 慢。
页面组件细分（随时间变化） 随着加压时间变化，持续观察各个组件耗时会不会慢慢变长（加压后图片加载越来越慢，说明服务器 / 带宽瓶颈）。
页面下载时间细分 整个页面完整下载下来的耗时拆解，从发起请求到页面全部收完。
页面下载时间细分（随时间变化） 看持续加压下，页面下载时间会不会逐步上涨（性能退化）。
第一次缓冲细分时间（第一次缓冲时间 TTFB 相关） 客户端发完请求，第一次收到服务器返回数据包的间隔，俗称首包时间。这个时间高，大多是服务器后台处理慢（数据库慢、接口逻辑卡）。
第一次缓冲时间细分（随时间变化） 看随着并发增加，首包时间会不会越来越久。
已下载组件大小 每个组件的文件大小（图片多大、js 多大），用来判断是不是资源太大导致加载慢。

✅考试一句话区分（背这个）

Web 请求指标：统计请求、连接、流量、点击、页面个数（是 “多少次、多少流量”）
Web 页面组件指标：统计页面里面每一个资源的耗时、大小（是 “每个东西花多久加载”，用来定位瓶颈）

Hits（点击数 / 每秒点击次数）：浏览器向服务器发的每一次独立请求，就算 1 hit Page（页面数）：浏览器认定【一个 HTML 主页面加载完成】，才算 1 个 Page

先回答你的例子：点登录按钮，跳转到登录页

登录页这个页面，本身是一份 html 文件，页面里还带：登录页背景图、logo 图片、css 样式文件、js 校验脚本。假设登录页面包含：

login.html（主页面文件）
logo.png
bg.jpg
style.css
login.js

👉 当你点按钮，浏览器加载这个登录页面：

页面 Pages + 1（只有 login.html 是主页面，只算 1 页）
Hits（点击数） + 5 （html、logo、背景图、css、js，一共发了 5 次请求，5 个 hit）

✅ 所以：你只手动点了 1 下按钮，但是后台统计的 Hits 是 5 次！

这里最容易混淆：我们人用手点一次 ≠ 性能工具里统计的 hit（每秒点击次数）工具里的 hit，不是人的手指点击动作，是浏览器发给服务器的每一次资源请求！！

一、服务器操作系统资源（4 项：内存、CPU、文件系统、磁盘管理）

就类比成奶茶店后厨本身：后厨的灶台、储物空间、柜子、水管。

CPU：后厨厨师，负责计算、处理请求。
- CPU 使用率太高（比如持续 95% 以上）= 厨师忙到爆炸，处理越来越慢，响应时间变长
- 压力测试重点看：CPU 利用率、队列等待
内存：后厨临时操作台。临时放要用到的数据；内存不够，系统就会频繁拿磁盘当临时内存（交换 swap），一下子就会卡。
文件系统：服务器管理所有文件的一套规则（网页文件、日志、程序文件）。监控看：目录有没有满、文件读写会不会卡住。
磁盘管理：后厨储物货架（硬盘）。看硬盘读写速度、磁盘繁忙率、磁盘空间。磁盘是常见瓶颈：大量读写数据库的时候，硬盘跑不动。

✅ 这四个，属于操作系统层面，不管跑什么软件、什么数据库，服务器本身都要监控这四项。

二、数据库资源（下面 3 条）

奶茶店的订单记录本，专门管存订单、查订单，这是数据库独有的监控项：

监控超出共享内存缓冲区的操作数 先解释共享内存缓冲区：数据库会把经常查的数据，提前放到内存缓冲区里，查的时候直接读内存，很快。

缓冲区 = 桌子上随手能拿到的账本；磁盘 = 柜子深处放的大本账本如果查询的数据不在缓冲区里，就要跑到硬盘去读，这个叫缓冲区不命中（缺页）。监控这个数字：数字越大，说明频繁去硬盘找数据，数据库很慢，是瓶颈！考试一句话：这个指标高 → 缓存不够，磁盘 IO 压力大。

扩展的会话 / 用户检查以及参数控制 会话 = 数据库连接，就是程序和数据库建立的通道。比如：1000 个用户同时登录下单，就要开启很多数据库会话连接。

监控：一共有多少数据库会话、有没有会话堆积、有没有死锁、连接数有没有超过数据库最大限制
参数控制：数据库本身的配置（比如最大连接数、缓存大小这些参数），压力大的时候参数不合适就崩。

磁盘数据库自己大量读写磁盘（增删改查都要落盘存数据）。这里和上面操作系统的磁盘不是完全重复：操作系统磁盘看整块硬盘；这里是专门看数据库产生的磁盘读写压力（数据库读写日志、写数据文件）。

【考试区分，背这个】

Web 请求 / 页面指标：用户侧、业务侧（页面加载、点击、吞吐量）
本图【服务器操作系统资源】：机器硬件层面（CPU、内存、磁盘，所有程序共用）
本图【数据库资源】：数据库软件内部（缓存、会话连接、数据库磁盘读写）

做题经典逻辑链（性能排查思路，选择题经常考）

加压 → 页面响应变慢第一步：先看业务指标（响应时间、报错）第二步：看服务器资源：是不是 CPU / 内存 / 磁盘满了？第三步：如果服务器硬件资源还有富余 → 去查数据库：是不是缓存命中率低、会话太多、数据库磁盘读太多？

举个例子：并发上来之后，页面加载越来越慢，CPU 只用了 40%（CPU 很闲），那瓶颈大概率不在服务器 CPU，要去查数据库缓冲区、数据库磁盘。

TCP（大白话，软考版本）

TCP 是传输控制协议，属于传输层。你可以理解成：一条稳定的电话线。

建立连接 → 双方打招呼（三次握手）
数据一段一段传，保证不丢包、不乱序
传完挂断（四次挥手）

特点：可靠、有连接。我们上网、HTTP、HTTPS 底层都跑在 TCP 上。 👉 对应图里的：TCP 连接数，就是客户端和服务器之间建立好的这条 “电话线” 数量。

举例子：你打开网页，浏览器先和服务器建立 TCP 连接，之后才发送 HTTP 请求。短连接：看完页面就挂断；长连接：电话线保持一段时间不挂断，反复传数据。

SSL（现在叫 TLS，考试里常写 SSL）

SSL 是给 TCP 这条通道加密的外套。 HTTP 本身是明文传输，别人抓包就能看到你发了什么；套上 SSL 之后，变成 HTTPS，传输内容被加密。

要先做SSL 握手：双方交换加密信息、协商密钥
握手非常消耗服务器 CPU 资源（所以压力测试里很关注【每秒 SSL 连接数】）

简单链路： 浏览器 ↔【TCP通道】 ↔【SSL加密包裹】 ↔ HTTP数据

考试区分一句话背诵

TCP：负责建立稳定通道，保证数据送到（通路）
SSL/TLS：负责给通道加密，防止数据被偷看篡改（加密壳）

总结：

软件测评师｜性能指标汇总背诵清单（三张图合并，考试直接背）

分层逻辑（做题排查顺序）：业务 Web 指标 → 服务器系统资源 → 数据库资源

第一层：交易处理 - Web 请求指标（用户、浏览器、请求层面）

核心：统计浏览器发给服务器的请求、流量、连接

每秒点击次数 (Hits)：浏览器每发起 1 次 HTTP 资源请求（html / 图片 /css/js）算 1 次，≠人鼠标点一下，一个页面会产生很多 hits
点击次数摘要：总点击、最大 / 最小 / 平均点击
吞吐量：每秒传输的数据量（字节 /s），看流量大小，不是次数
吞吐量摘要：吞吐的汇总统计
HTTP 状态代码摘要：200 成功、404、500、302 等，统计报错
每秒 HTTP 响应数：服务器每秒返回应答的数量
每秒下载页面数 (Pages)：完整加载 1 个 HTML 主页才算 1 页；1 页 = 多个 hits
每秒重试次数：请求失败后重新发起的请求次数，多代表不稳
重试次数摘要：重试汇总
连接数：当前已经建立的 TCP 连接总数
每秒连接数：每秒新建 TCP 连接
每秒 SSL 连接数：每秒新建 HTTPS 加密握手连接，非常耗 CPU

✅ 口诀：hit 是细碎资源请求，page 是用户眼里一整页；吞吐看流量，连接看通道

第二层：交易处理 - Web 页面组件指标（拆网页，定位页面里面哪里慢）

核心：把一个网页拆开，看每个图片、脚本、资源的加载耗时

激活网页细分：拆解一个页面全链路耗时（DNS、连接、SSL、发请求、服务处理、收数据）
页面组件细分：单独统计每个组件（图、js、css）的耗时，定位哪个资源拖慢页面
页面组件细分（随时间变化）：加压过程中，持续看组件耗时会不会越来越长
页面下载时间细分：整个页面全部下载完成的耗时拆解
页面下载时间细分（随时间变化）：加压下页面下载耗时变化，判断性能退化
第一次缓冲细分时间（首包 TTFB）：发完请求，等到服务器返回第一个数据包的时间，这个大 = 后台处理慢（数据库 / 代码慢）
第一次缓冲时间细分（随时间变化）：并发上涨，观察首包时间变化
已下载组件大小：每个资源文件大小，判断是不是资源太大

✅ 口诀：组件指标，用来拆页面，找到是哪一张图、哪一个脚本加载慢

第三层：服务器操作系统资源（服务器底层硬件，所有程序共用）

核心：机器本身资源，先看这一层，判断硬件有没有顶满

CPU：相当于厨师，负责运算；使用率过高、等待队列长就是瓶颈
内存：临时操作台；内存不足会大量 swap 交换到磁盘，直接卡顿
文件系统：管理服务器上所有文件，监控文件占用、读写异常
磁盘管理：硬盘；看磁盘繁忙度、IO 读写速度、磁盘空间，磁盘是高频瓶颈

✅ 口诀：CPU 算、内存缓存、磁盘存文件，这是服务器底子

第四层：数据库资源（数据库软件内部专属指标）

硬件资源没满，响应还是慢，就查这里

监控超出共享内存缓冲区的操作数共享缓冲区 = 数据库内存缓存，放常用数据；这个数值高 = 缓存没命中，频繁读硬盘，数据库慢
扩展的会话 / 用户检查以及参数控制会话 = 数据库连接通道；监控连接总数、死锁、堆积，检查数据库最大连接等配置参数
磁盘：数据库专属磁盘 IO（写日志、读写表数据），和操作系统磁盘监控侧重点不一样

✅ 口诀：缓存不命中读硬盘，连接太多堵数据库

🔥 考试排查逻辑链（大题、选择题必考思路）

加压 → 用户页面响应变慢

先看【Web 指标】：响应时间、报错、重试有没有上涨
再看【服务器系统资源】：CPU / 内存 / 磁盘是不是跑满了
硬件资源充足 → 再查【数据库指标】：缓存命中率、会话连接、数据库磁盘 IO

📌 易混点极简对比（考前快速过）

Hits（每秒点击）：每一个资源请求 ✦ Pages（每秒页面）：一整个 HTML 页面
TCP 连接：基础传输通道 ✦ SSL 连接：TCP 通道上加加密握手（HTTPS）
操作系统磁盘：整机硬盘 ✦ 数据库磁盘：数据库产生的读写压力
Web 组件指标：页面里每个资源耗时 ✦ Web 请求指标：请求次数、流量统计

第四块：中间件服务器监控（加到咱们之前的背诵清单里，软测评师考点）

一句话定位：前面三层：业务页面 → 服务器硬件 → 数据库； 中间件，夹在操作系统、数据库之间，是跑 Java / 交易程序的容器。 Tuxedo、WebLogic、WebSphere 都是企业商用中间件，压力测试里专门监控这一层。

先分清三个中间件：

Tuxedo：老牌交易中间件（C 语言，银行、金融核心交易用的多，处理转账、支付这类事务）
WebLogic（Oracle）：Java 应用服务器
WebSphere（IBM）：IBM 的 Java 应用服务器

✅ 通用监控指标（三个中间件都看这几项，考试优先背）

线程池 / 工作队列（最重要！选择题高频）中间件里面处理请求的 “工人”。线程全部占满排队，新请求就卡住、超时。监控：活跃线程数、队列排队请求数、线程空闲数量。

类比：奶茶店里面接单服务员，如果全部忙死，顾客就要排队等。

连接池（数据库连接池） 中间件去访问数据库的通道池。池子用光了，就算数据库还能扛，应用也拿不到数据库连接，直接报错。监控：最大连接、已使用连接、空闲连接。
JVM 资源（WebLogic / WebSphere 才有，Tuxedo 没有 JVM） 堆内存使用率、GC 垃圾回收频率、GC 耗时。 GC 频繁、堆内存占满 → 程序卡顿、OOM 崩溃。
会话 Session 数量 在线用户会话数，记录登录用户状态。会话太多会吃内存。
交易 / 请求吞吐量、平均处理耗时、报错数 中间件层面接收、处理请求的速度，交易成功率、事务回滚数量（金融 Tuxedo 重点看事务）
中间件服务状态：进程是否存活、服务启停状态

单独区分三个（简单记，不用深挖细节）

Tuxedo（交易中间件） 重点看：服务请求队列、事务数量、事务提交 / 回滚数、服务调用耗时、客户端连接数。主打分布式事务，银行系统用。
WebLogic（Oracle） 重点：JVM 堆、线程池、数据源连接池、EJB 组件、在线 session、集群状态。
WebSphere（IBM） 重点：线程池、连接池、JVM GC、消息队列、Servlet/EJB 响应时间。

📌 把排查链更新完整（现在是完整 4 层）

加压后页面变慢，排查顺序：

Web 业务指标：响应时间、报错、重试
操作系统资源：CPU、内存、磁盘
✅【中间件】：线程池是不是堵了？连接池用完？JVM 频繁 GC？
数据库资源：缓存命中率、会话、磁盘 IO

很多时候，服务器 CPU 还有富余、数据库也没事，瓶颈卡在中间件线程池满了！这个是考试最喜欢挖坑的地方。

一句话口诀

线程池堵、连接池耗尽、JVM 疯狂 GC，是中间件三大瓶颈！

现在完整四层汇总（全部指标合在一起）

Web 请求指标：点击 Hits、页面 Page、吞吐量、连接、SSL
Web 页面组件指标：拆分页面每个资源耗时，定位页面哪里慢
服务器操作系统：CPU、内存、文件系统、磁盘
中间件监控：Tuxedo/WebLogic/WebSphere → 线程池、连接池、JVM、会话、交易事务
数据库资源：缓冲区缓存、数据库会话、数据库磁盘

举一个真实落地案例：电商【商品详情页秒杀负载压力测试】

对应你书上的 9 步，一步一步对齐，场景贴近软件测评师考试，也好理解

业务背景：电商系统，商品详情页，准备做秒杀活动；预估最多同时 5000 用户进来刷页面、下单。我们要做负载 & 压力测试，看看系统扛不扛得住。被测链路：用户浏览器 → Nginx → WebLogic 中间件 → 业务代码 → MySQL 数据库

第一步：测试计划（书上第一步）

确定： ✅ 测试对象：商品详情页、秒杀下单接口 ✅ 系统配置：服务器几台、WebLogic 集群配置、数据库主从配置 ✅ 使用模式：用户行为：打开详情页 → 刷新页面 → 点击下单（和真实用户操作一样） ✅ 目标：并发 5000 用户时，页面响应时间≤2s，成功率 99.9%；压力测试看系统多少并发会崩

第二步：测试需求分析（书上第二步）

测试策略 先做负载测试（慢慢加到 5000 并发，看能不能稳定跑）；再做压力测试，超过 5000 继续加压，找到崩溃临界点。
测试案例 案例 1：普通负载：5000 并发用户持续访问详情页案例 2：压力场景：逐步加压到 8000，观察什么时候报错、超时案例 3：稳定性：3000 并发持续跑 2 小时，看会不会慢慢变慢、内存泄漏
测试内容 监控前面我们学的所有指标：web 请求指标、服务器 CPU 内存、WebLogic 中间件线程池、数据库缓冲区、磁盘 IO

第三步：测试案例制定（书上第三步）

写清楚每个场景：比如场景 A：虚拟用户 Vuser：5000 人加压方式：阶梯加压，每 30 秒增加 500 用户持续运行 15 分钟预期指标：响应时间 < 2s，报错率 < 0.1%

第四步：测试环境、工具、数据准备（书上第四步）

工具：LoadRunner（教材里经典工具，软考默认它）
测试环境：独立压测环境，不和线上共用；配置和线上一致
测试数据：准备好测试商品、测试账号、提前造好商品库存数据；避免脏数据影响结果

第五步：测试脚本录制、编写与调试（书上第五步，Vuser 就是虚拟用户）

创建 Vuser 组：一组虚拟用户，模拟访问详情页、下单
配置 Vuser：录制用户操作脚本：打开详情页、刷新、提交下单
Vuser 运行设置：设置思考时间（模拟人看完页面停顿几秒，不能不停疯狂点）
配置负载生成器：多台压力机，一台机器发 5000 请求会打不动，多台机器一起发压力
设置事务：把 “打开详情页”、“提交下单” 设置成事务，单独统计每个步骤响应时间
WAN 仿真（可选）：模拟弱网，比如用户手机 4G 网络延迟
调试脚本：跑少量用户（10 个），确认脚本不会报错，能正常提交下单

Vuser = 虚拟用户，就是工具模拟出来的人，一个 Vuser 代表一个用户

第六步：场景制定（书上第六步）

在 LoadRunner 里面建好压测场景：选择刚才调试好的脚本，设置加压模式：阶梯加压，设置持续时长、停止条件（报错超过 5% 自动停止），绑定负载生成器。

第七步：测试执行（书上第七步）

启动场景，开始跑压测
实时看 Vuser 状态：哪些虚拟用户成功、哪些报错
开启监控：一边跑，一边采集我们前面学的所有指标：
- Web 指标：吞吐量、Hits、页面响应时间、HTTP 报错码
- 服务器：CPU、内存、磁盘
- WebLogic 中间件：线程池、连接池、JVM GC
- 数据库：缓冲区命中、会话、磁盘 IO

第八步：获取测试结果（书上第八步）

跑完之后，工具自动出一大堆图表：

交易性能：响应时间曲线、每秒页面数、吞吐量、失败交易数量
资源占用：CPU 变化曲线、内存变化、线程池占用曲线
故障信息：哪些请求超时、哪里报错

第九步：结果评估 + 测试报告（书上第九步）

我们拿到数据开始分析：

交易评估：加到 5000 并发的时候，下单响应时间到 3.5s，超过 2s 目标，不达标
资源评估：查看监控，发现 WebLogic 的数据库连接池全部耗尽，排队等待连接
故障定位：瓶颈不是 CPU、不是数据库，是中间件连接池配置太小 👉 结论：需要调大 WebLogic 数据库连接池，优化后重新复测。最后整理报告：写清楚场景、数据、瓶颈、优化建议。

✅ 帮你串一下考试答题话术（简答直接背）

负载压力测试实施流程：

测试计划：确定测试对象、系统配置、用户使用模式
需求分析：确定测试策略、案例、测试内容
制定测试案例
环境、工具、测试数据准备
脚本开发调试：创建 Vuser、配置虚拟用户、负载机、事务、脚本调试
压测场景设计
执行场景，运行压测，实时监控
采集性能结果数据
评估结果，分析故障，输出测试报告

✅ 你容易混淆的点

Vuser（虚拟用户）≠ 并发数：脚本里的 Vuser 是模拟用户；场景里设置同时跑多少个 Vuser，这个才是并发。

✅ 配套理解我们之前学的指标

跑这个秒杀压测的时候，监控的就是前面 4 层指标：web 页面指标、服务器资源、中间件、数据库指标，刚好串起来整套知识。

posted on 2026-10-22 11:18 轻微强迫症阅读(16) 评论(0) 收藏举报