一、项目背景
为验证本地商城系统在多用户并发场景下的性能表现，基于 JMeter 设计并执行了一次阶梯式性能压测。本次测试重点聚焦于商城核心业务链路（商品查询、登录、首页图片加载等），目标是评估系统在 20 用户并发 下的稳定性、响应延迟与处理能力，并定位高并发下的性能瓶颈。
二、压测设计与实现
1. 加压模型
采用 jp@gc - Stepping Thread Group 阶梯式线程组，模拟真实用户量逐步增长的过程：
- 初始用户数：0
- 加压策略：每 10 秒增加 5 个用户，最高 20 用户并发
- 稳定负载：峰值并发保持 60 秒
- 减压策略：每秒减少 1 个用户，模拟用户自然退出
2. 测试接口与场景
覆盖商城核心业务接口，包含：
- 商品列表接口：获取商品基础列表数据
- 商品分类接口：查询商品分类层级关系
- 验证登录接口：用户身份验证与 Token 生成
- 对应版块下的商品接口：按分类筛选商品数据
- 版块列表接口：获取版块 / 分类列表
- 首页图片接口：首页静态资源 / 图片加载（大流量、高并发场景）
- 接口配置同步定时器，确保请求的业务正确性与加压节奏可控。
三、压测结果解读
1. 聚合报告核心指标
本次压测共生成 1657 个样本 ，总体平均响应时间 909ms ，整体吞吐量 14.6/sec。核心数据解读如下：
| 列名 | 含义（人话版） | 结果解读 |
|---|---|---|
| Label | 接口 / 事务名称 | 包含 6 个核心业务接口，覆盖商城全流程 |
| #样本 | 总请求次数 | 首页图片接口请求量最大 (4441 次)，验证登录接口最低 (276 次)，总样本 1657，数据覆盖主要业务场景 |
| 平均值 | 平均响应时间 (ms) | 首页图片接口平均 4441ms，为性能瓶颈点；其他业务接口集中在 117-183ms，整体响应适中 |
| 中位数 | 50% 请求响应时间 | 集中在 115-200ms，与平均值基本一致，说明响应时间分布稳定，无剧烈波动 |
| 90% 百分位 | 90% 请求响应时间 | 首页图片接口达 8540ms，远超正常阈值，是严重性能瓶颈；其他接口均在 396-518ms 内，用户体验可接受 |
| 99% 百分位 | 99% 请求响应时间 | 首页图片接口飙升至 11962ms，存在大量长尾慢请求；其他接口最高 1151ms，整体可控 |
| 最大值 | 最大响应时间 | 首页图片接口达到 46845ms（约 46 秒），严重拖慢系统整体响应 |
| 异常 % | 请求失败率 | 总体 0.00%，所有接口均成功响应，无业务报错或超时中断 |
| 吞吐量 | 系统 TPS | 总体 14.6/sec，单接口吞吐量集中在 2.5-2.6/sec，系统处理能力有限 |
| 接收 / 发送 | 网络流量 | 首页图片接口接收流量高达 428.09KB/s，远高于其他接口，是数据量最大接口 |
核心结论：
- 稳：整体成功率 100%，无报错，系统在高并发下业务逻辑正常，未崩溃。
- 慢 ：首页图片接口是绝对性能瓶颈，响应时间达 46 秒，99% 请求超 11 秒，严重影响用户体验。
- 快：商品列表、分类、登录等核心业务接口响应时间均在 500ms 内，表现良好。
2. 官方 Dashboard 关键图表解读
除聚合报告外，通过 JMeter 生成的 HTML 仪表盘进行多维度可视化分析：
（1）APDEX 性能满意度指标
APDEX（Application Performance Index）是衡量用户满意度的行业标准（0-1 分，越接近 1 越优秀）：
- 总体 APDEX：0.828：整体处于「合格」水平，但低于论坛系统。
- 各接口得分 ：版块列表接口 (0.991) > 商品分类接口 (0.993) > 验证登录接口 (0.993) > 对应版块下的商品接口 (0.977) > 商品列表接口 (0.926) > 首页图片接口 (0.126)。
- 关键解读 ：首页图片接口 APDEX 仅为 0.126，意味着绝大多数用户（超 90%）对该接口的响应感到不满。这与聚合报告中该接口响应时间激增的现象完全一致，是本次压测最核心的优化点。
（2）请求成功率统计
饼图显示总体请求成功率为 99.94% ，仅 0.06% 失败。
- 失败请求全部来自 首页图片接口，说明该接口虽然未能完成快速响应，但最终仍有极少部分请求超时失败，进一步印证了其作为瓶颈的稳定性问题。
- 其他业务接口（商品、登录等）均为 100% 成功，证明商城业务逻辑本身健壮。
（3）响应时间趋势图（Response Times Over Time）
图表展示了压测全过程中各接口响应时间的变化：
- 整体趋势 ：随压测时间推进，所有接口响应时间均呈持续上升趋势，尤其在压测后期（18:15:56 左右）急剧攀升。
- 首页图片接口：曲线呈垂直飙升态势，从初期的几百毫秒迅速突破至数万毫秒，形成尖锐的「尖刺」，是响应时间增长的主导因素。
- 其他接口：虽有增长，但幅度远小于首页图片接口，说明系统资源消耗主要被图片加载接口占用。
（4）响应时间百分位趋势图 (Response Time Percentiles Over Time)
该图展示了不同分位值（90/95/99/Max）的响应时间变化：
- 曲线形态 ：所有分位线均呈陡峭上升趋势，尤其是 Max（最大值） 和 99th 百分位。
- 长尾效应 ：99th 百分位曲线与 Max 曲线几乎重合，且数值巨大，表明压测过程中存在大量极端慢请求。
- 结论 ：系统在高并发下出现了严重的请求排队和处理延迟，首页图片接口成为拖垮整体性能的单点。
3. 动态监控图表分析
（1）TPS 趋势图（Transactions Per Second）
- 曲线形态：TPS 随线程数增加先上升至峰值（约 2.8 TPS），随后迅速下降。
- 对比分析 ：与论坛系统（23 TPS）相比，商城系统峰值吞吐量仅为其 1/8，说明系统处理能力存在明显短板。
- 原因定位：TPS 峰值后快速回落，与首页图片接口响应时间激增同步，证明该接口成为性能瓶颈，导致后续请求无法及时处理，系统吞吐量下降。
四、问题分析与优化建议
1. 存在的核心问题
- 首页图片接口严重超时：响应时间达 46845ms，APDEX 垫底，是系统性能最大短板。
- 系统吞吐量偏低：总体 TPS 仅 14.6/sec，对比论坛系统（97.2 TPS），处理能力差距较大。
- 资源竞争激烈：图片加载接口占用大量系统资源（IO、带宽、连接池），导致其他业务接口响应时间随并发增加而线性增长。
2. 优化方向
- 静态资源加速（首要） ：
- 实施 CDN 加速，将首页图片 / 静态资源部署至 CDN 节点，降低跨网传输时间。
- 开启 浏览器缓存，设置合理的 Cache-Control，减少重复请求。
- 实施 图片压缩与懒加载，减小传输体积与请求次数。
- 服务端优化 ：
- 优化图片服务端代码，提升并发处理能力。
- 考虑引入 Nginx 静态资源服务，直接由 Nginx 处理图片请求，减轻应用服务器压力。
- 系统扩容 ：
- 针对图片接口进行独立部署，实现业务与静态资源分离。
- 升级服务器带宽配置，解决大文件传输瓶颈。
五、项目总结
本次商城系统压测验证了系统在 20 用户并发下的业务可用性 （100% 成功率），但同时也暴露了严重的性能短板：
- 整体性能：平均响应时间 909ms，峰值 TPS 仅 2.8，系统处理能力较弱。
- 关键瓶颈 ：首页图片接口是性能杀手，响应时间超 46 秒，需优先通过 CDN、缓存、压缩等手段进行优化。
- 优化空间：相比论坛系统，商城系统在静态资源处理上存在明显不足。通过针对性优化，系统性能有望提升数倍，完全满足日常业务需求。
此次压测为商城系统的后续性能迭代提供了精准的数据支撑，明确了优化的优先级与方向。