卷王问卷考试系统 JMeter 压测报告分析

一、测试整体概况

本次对系统核心接口进行梯度压测，测试时长约3分钟，总请求数1531次，全链路错误率0.00%，无请求失败、超时或服务崩溃，系统在压测压力下基础稳定性达标，未出现严重可用性问题。

二、核心指标深度分析

1. 响应时间与用户体验（APDEX + 聚合统计）

• 整体表现：总平均响应时间1076ms，但中位数仅218ms，说明大部分请求响应很快，但少数长尾请求严重拉高了平均值。99分位响应时间高达18895ms（近19秒），最大响应时间26119ms（26秒），存在严重的性能长尾问题。
• APDEX用户体验分层（以T=500ms、F=1500ms为标准）：
  • 优秀接口（APDEX>0.9）：修改密码、删除字典、查询字典等轻量操作，响应快，用户体验达标；
  • 一般接口（0.5<APDEX<0.9）：登录、新建问卷、查询题库等，大部分请求在1500ms内，但仍有部分请求超时；
  • 严重问题接口（APDEX<0.3）：获取当前用户创建的问卷和考试的数量（APDEX=0.023，平均响应15587ms，最大26119ms）、获取项目文件夹列表（平均6722ms），几乎所有请求都超过1500ms，用户体验极差，是核心性能瓶颈。
• 业务特征：慢请求集中在用户维度的批量查询接口，这类接口大概率存在全表扫描、无分页、无缓存问题，随着数据量增长，性能会持续恶化。

2. 性能趋势与衰减问题（时间变化图）

• 响应时间随压测持续上升：随着线程数从15增加到20（梯度上升），平均响应时间、分位响应时间均持续攀升，尤其是慢接口响应时间从10s升至20s以上，说明系统存在性能衰减问题——并发压力增加时，服务器处理效率下降，请求排队、资源竞争加剧。
• 吞吐量触达瓶颈：总吞吐量仅15.04/sec，字节吞吐量在压测中期达到峰值后下降，说明系统已无法通过增加线程数提升处理能力，反而因资源耗尽导致效率下降。
• 问题定位：连接时间曲线几乎为0，说明网络连接无问题，所有延迟均来自服务器业务逻辑处理和数据库查询。

3. 接口性能分层

三、核心问题总结

1. 无服务可用性风险：全链路错误率0%，系统基础稳定性达标；
2. 严重的长尾性能问题：少数用户维度批量查询接口响应时间极长，是用户体验的主要短板；
3. 性能衰减明显：并发压力增加时，响应时间持续上升、吞吐量下降，存在资源竞争和瓶颈；
4. 接口性能分层严重：轻量操作性能优秀，但批量查询接口几乎不可用，无法支撑大数据量场景。

四、针对性优化建议

1. 慢接口专项优化（优先级最高）

• 用户创建的问卷/考试列表接口：
  • 增加分页查询，禁止一次性查询用户所有数据；
  • 为用户ID创建时间等查询条件添加数据库索引，避免全表扫描；
  • 引入Redis缓存，缓存用户的问卷/考试列表并设置过期时间，减少数据库压力；
  • 优化SQL语句，避免关联查询、子查询导致的性能损耗。
• 其他慢接口（如项目文件夹列表）：
  • 检查是否存在循环查询、N+1问题；
  • 简化查询逻辑，减少不必要的字段查询。

2. 系统层面调优

• 数据库优化：
  • 开启慢查询日志，定位执行时间长的SQL；
  • 调整数据库连接池参数，避免连接耗尽；
  • 高频查询表可考虑读写分离或分库分表（数据量较大时）。
• 应用层优化：
  • 为高频查询接口添加本地缓存或分布式缓存；
  • 对批量操作设置限流，避免单个请求占用过多资源；
  • 排查内存泄漏问题，避免压测过程中内存占用持续升高、GC频繁。

3. 后续压测验证

• 单独针对慢接口进行专项压测，模拟用户创建大量问卷/考试的场景，验证优化效果；
• 优化JMeter压测配置，增加ramp-up时间，模拟更真实的用户并发场景；
• 压测时同步监控服务器CPU、内存、磁盘IO和数据库连接数，定位资源瓶颈。

五、最终结论

系统基础稳定性达标，但核心的用户维度批量查询接口存在严重性能瓶颈，导致用户体验差和性能衰减。需优先优化慢接口，再进行系统层面调优，才能支撑更高并发和更大数据量的使用场景。