一、测试整体概况
本次对系统核心接口进行梯度压测，测试时长约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. 接口性能分层
| 性能等级 | 特征 | 代表接口 | 问题分析 |
|---|---|---|---|
| 优秀 | 平均<100ms，APDEX>0.9 | 修改密码、删除岗位、编辑字典 | 轻量操作，无复杂查询，性能达标 |
| 一般 | 平均100-1000ms，APDEX 0.5-0.9 | 登录、新建问卷、查询题库 | 有一定业务逻辑，但未出现明显瓶颈 |
| 差 | 平均>1000ms，APDEX<0.5 | 获取用户创建的问卷列表、获取项目文件夹列表 | 批量查询无优化，存在严重性能问题 |
三、核心问题总结
- 无服务可用性风险：全链路错误率0%，系统基础稳定性达标；
- 严重的长尾性能问题：少数用户维度批量查询接口响应时间极长，是用户体验的主要短板；
- 性能衰减明显：并发压力增加时，响应时间持续上升、吞吐量下降，存在资源竞争和瓶颈；
- 接口性能分层严重：轻量操作性能优秀，但批量查询接口几乎不可用，无法支撑大数据量场景。
四、针对性优化建议
1. 慢接口专项优化（优先级最高）
- 用户创建的问卷/考试列表接口：
- 增加分页查询，禁止一次性查询用户所有数据；
- 为
用户ID创建时间等查询条件添加数据库索引，避免全表扫描； - 引入Redis缓存，缓存用户的问卷/考试列表并设置过期时间，减少数据库压力；
- 优化SQL语句，避免关联查询、子查询导致的性能损耗。
- 其他慢接口（如项目文件夹列表）：
- 检查是否存在循环查询、N+1问题；
- 简化查询逻辑，减少不必要的字段查询。
2. 系统层面调优
- 数据库优化：
- 开启慢查询日志，定位执行时间长的SQL；
- 调整数据库连接池参数，避免连接耗尽；
- 高频查询表可考虑读写分离或分库分表（数据量较大时）。
- 应用层优化：
- 为高频查询接口添加本地缓存或分布式缓存；
- 对批量操作设置限流，避免单个请求占用过多资源；
- 排查内存泄漏问题，避免压测过程中内存占用持续升高、GC频繁。
3. 后续压测验证
- 单独针对慢接口进行专项压测，模拟用户创建大量问卷/考试的场景，验证优化效果；
- 优化JMeter压测配置，增加ramp-up时间，模拟更真实的用户并发场景；
- 压测时同步监控服务器CPU、内存、磁盘IO和数据库连接数，定位资源瓶颈。
五、最终结论
系统基础稳定性达标，但核心的用户维度批量查询接口存在严重性能瓶颈，导致用户体验差和性能衰减。需优先优化慢接口，再进行系统层面调优，才能支撑更高并发和更大数据量的使用场景。
