前言

星选抽奖系统作为面向线上活动场景的抽奖管理平台，核心业务需支撑活动高峰期的高并发访问，其性能表现直接决定了活动的稳定性与用户体验。本次以测试工程师视角，针对系统全业务链路开展专项性能压测，通过梯度负载模型模拟真实线上流量场景，量化系统性能指标，精准定位性能瓶颈，最终给出可落地的优化方案，为系统线上稳定运行提供数据支撑与测试依据。

---

一、压测基础信息

1.1 压测目标

1. 验证系统在持续并发负载下的服务稳定性，确认是否存在服务宕机、接口报错、数据异常等问题；
2. 量化核心业务接口的响应性能、并发承载能力，验证是否满足线上活动的用户体验要求；
3. 定位系统性能瓶颈，明确优化优先级与落地路径；
4. 验证系统在负载变化过程中的性能表现，排查是否存在性能持续恶化的风险。

1.2 压测环境与工具

• 压测工具：Apache JMeter 5.x，配套第三方插件实现阶梯线程组控制、时序指标监控、HTML可视化报告生成；
• 被测系统：星选抽奖系统，采用SpringBoot+MyBatis技术栈开发，核心接口通过JWT做身份认证；
• 压测范围：覆盖手机号登录、用户注册、人员/奖品/活动全量与分页查询、奖品/活动创建、在线抽奖、中奖记录查询全业务链路，合计14个核心接口；
• 性能判定标准：采用Web系统通用APDEX标准，容忍阈值T=500ms（用户无感知卡顿），挫败阈值F=1500ms（用户体验明显下降）。

1.3 压测模型设计

本次采用梯度降载的负载模型，模拟线上活动流量逐步回落的真实场景：初始并发线程数11，随压测时长线性降低至7，全程持续发起业务请求，累计压测时长1分钟，覆盖负载从高到低的全流程，确保测试结果贴合真实业务场景。

---

二、压测整体结果总览

本次压测累计发起1330次业务请求，核心整体指标如下：

1. 服务稳定性：全压测周期接口错误率0.00%，请求成功率100%，无服务宕机、无接口超时熔断、无数据一致性问题，系统基础架构稳定性达标；
2. 整体性能指标：系统整体平均响应时间394.09ms，中位数36.00ms，90%请求响应≤914.40ms，95%请求≤1449.50ms，99%请求≤4727.07ms，整体吞吐量20.71 transactions/sec，网络接收速率201.25KB/sec，发送速率18.01KB/sec；
3. 用户体验评分：系统整体APDEX应用性能指数0.903，处于「优秀」区间，说明绝大多数业务请求的响应速度符合用户体验要求，仅少数慢查询接口拉低了整体评分。

整体结论先行：系统核心业务链路性能达标、稳定性合格，但存在2个致命级别的慢查询接口，已成为系统性能瓶颈，必须完成优化后方可支撑线上高并发活动场景。

---

三、接口维度性能详细分析

基于本次压测的聚合报告与APDEX指数表，将全量接口分为「核心达标接口」与「风险瓶颈接口」两类，所有分析数据100%匹配压测原始结果。

3.1 性能达标核心业务接口

这类接口为系统核心业务链路，覆盖用户最常用的抽奖、登录、活动/奖品管理等场景，平均响应时间均控制在100ms以内，APDEX指数均接近或达到满分1.000，完全满足线上业务的性能要求，无性能瓶颈。

接口名称	累计请求数	平均响应时间	99%分位响应时间	吞吐量	APDEX指数	性能评价
活动抽奖（核心接口）	186	38.22ms	350.17ms	3.94次/秒	1.000	优秀，作为系统最核心的写操作接口，高并发下响应稳定无抖动，抽奖逻辑高效，无库存扣减、数据落库带来的性能损耗
获取中奖记录（活动维度）	91	31.98ms	123.00ms	1.93次/秒	1.000	优秀，高频查询接口响应极速，完全适配活动高峰期用户频繁查询中奖结果的场景
新建抽奖活动	91	41.82ms	153.00ms	1.92次/秒	1.000	优秀，后台配置类接口性能稳定，无并发压力
创建奖品	93	45.62ms	355.00ms	1.97次/秒	1.000	优秀，支持图片上传场景，业务逻辑无性能损耗
获取活动详情	91	38.70ms	341.00ms	1.93次/秒	1.000	优秀，查询响应平稳，无性能瓶颈
获取活动列表（分页）	91	42.99ms	328.00ms	1.93次/秒	1.000	优秀，分页查询逻辑高效，无全表扫描风险
获取奖品列表（分页）	93	44.99ms	354.00ms	1.97次/秒	1.000	优秀，分页查询性能稳定，与全量查询接口形成鲜明对比
手机号登录	103	88.12ms	1512.24ms	2.11次/秒	0.985	良好，JWT认证逻辑高效，平均响应延迟极低，仅极端场景下存在轻微长尾波动，完全满足登录场景的业务需求
注册普通用户	103	412.69ms	2083.32ms	2.11次/秒	0.908	良好，注册逻辑稳定，平均响应在可接受范围，仅极端场景下延迟超阈值，无核心性能瓶颈

3.2 存在严重性能瓶颈的风险接口

这类接口是本次压测暴露的核心问题，平均响应时间超1秒，APDEX指数低于0.5，处于「不可接受」区间，最大延迟超15秒，直接拉低了系统整体性能评分，存在严重的线上超时风险，为最高优化优先级。

接口名称	累计请求数	平均响应时间	99%分位响应时间	最大响应时间	吞吐量	APDEX指数	风险等级
获取人员列表	101	2624.41ms	31032.30ms	31048ms	1.61次/秒	0.460	致命
获取所有的奖品列表	93	1558.70ms	16376.00ms	16376ms	1.96次/秒	0.435	致命
获取所有的人员列表	91	355.18ms	2763.00ms	2763ms	1.92次/秒	0.874	中风险

关键问题分析：

1. 获取人员列表接口平均响应超2.6秒，极端场景下最大延迟超30秒，意味着1%的用户请求需要等待30秒以上才能拿到结果，线上场景下会直接触发前端超时、页面卡死，是系统最大的性能瓶颈；
2. 获取所有的奖品列表接口平均响应超1.5秒，最大延迟超16秒，APDEX指数仅0.435，为系统第二大性能瓶颈；
3. 对比同业务的分页查询接口，全量列表查询接口性能差距超30倍，核心问题为接口未做分页限制、查询SQL无有效索引，存在严重的全表扫描问题。

---

四、时序趋势深度分析

基于本次压测生成的时序监控图表，从时间维度进一步分析系统性能变化规律，精准定位瓶颈根因：

4.1 响应时间随时间变化趋势

核心瓶颈接口「获取人员列表」的平均响应时间，从压测初始的1500ms左右，随压测时长持续线性飙升，最终达到11000ms以上，全程无回落；而其余所有业务接口的平均响应时间全程平稳，始终维持在100ms以内，无明显波动。
这一现象说明：慢查询接口在持续并发下，数据库IO瓶颈持续放大，性能持续恶化，无任何性能冗余；而核心业务链路性能冗余充足，不受持续并发的影响。

4.2 响应时间百分位变化趋势

接口90%、95%、99%分位延迟随压测时长持续线性上升，最大延迟峰值达31048ms，而中位数、最小响应时间全程保持平稳。
这一现象验证了：系统绝大多数请求性能正常，仅少数全量查询的慢接口，拖垮了系统整体的百分位指标，造成了严重的长尾效应，线上场景下会出现“大部分用户使用正常，少数用户完全打不开页面”的问题。

4.3 活跃线程与吞吐量变化趋势

本次压测活跃线程数从初始的11，随时间线性下降至7，在线程数持续降低、系统并发压力不断减小的情况下，慢查询接口的响应时间仍持续飙升；同时系统网络吞吐量随线程数下降同步降低，网络发送字节数全程平稳无波动。
这一现象直接证明：系统性能瓶颈与并发线程数无强关联，核心问题不在于服务器资源不足，而在于接口本身的业务逻辑与数据库设计缺陷；同时网络带宽、服务器出入口流量无任何瓶颈。

4.4 TCP连接时间变化趋势

系统TCP平均连接时间从初始的48ms平稳下降至28ms，全程无波动、无超时，说明网络层、TCP握手、服务器连接池、网关转发均无任何瓶颈，系统性能问题100%集中在应用层的业务逻辑与数据库层。

---

五、性能瓶颈根因定位

结合压测数据与时序分析，从测试工程师视角，精准定位性能瓶颈的核心根因：

1. 数据库层设计缺陷：慢查询接口均为全量列表查询，未强制添加分页限制，查询语句未针对查询条件建立有效索引，直接触发全表扫描；持续并发下数据库CPU、IO占用持续飙升，最终导致查询延迟线性恶化。
2. 缓存层完全缺失：人员信息、奖品信息属于低频变更的静态数据，未接入Redis等缓存组件，每次请求均直接穿透到数据库，造成了大量不必要的数据库IO压力，无法应对高频查询场景。
3. 业务逻辑冗余：全量查询接口未做字段裁剪，直接拉取全表全字段数据，增加了数据库处理开销与网络数据传输开销，进一步放大了接口延迟。
4. 服务容错机制缺失：慢查询接口未设置超时熔断、降级策略，高并发下会造成服务线程长时间阻塞，一旦流量进一步放大，极易引发服务雪崩效应。

---

六、针对性优化方案

基于瓶颈根因，按照优先级划分，给出可落地的优化方案：

6.1 P0级优化（上线前必须完成）

1. SQL与索引优化
   • 针对人员、奖品全量列表查询接口，强制添加分页参数（limit/offset），禁止前端无限制拉取全表数据，限制单页最大数据量；
   • 为查询条件字段（如id）建立B+树索引，彻底消除全表扫描，预计可降低90%以上的查询延迟。
2. 缓存层接入
   • 对人员信息、奖品信息、活动基础信息等低频变更数据，接入Redis缓存，设置合理的过期时间与双写更新机制，将热点查询请求拦截在缓存层，大幅降低数据库压力。
3. 熔断降级机制添加
   • 针对慢查询接口添加超时熔断策略，超过1秒未响应直接返回降级结果，避免单个慢接口拖垮整个服务的线程池。

6.2 P1级优化（体验提升，建议上线前完成）

1. 业务逻辑优化：精简全量查询接口的返回字段，仅返回前端必要字段，减少数据传输与数据库处理开销；优化注册接口的冗余校验与数据库操作，降低99%分位的长尾延迟。
2. 数据库连接池优化：调整数据库连接池的核心参数，提升高并发下的数据库连接复用率，减少连接创建与销毁的性能开销。

6.3 后续复测计划

1. 完成上述优化后，重新开展同等模型的梯度压测，验证慢接口优化效果，确保优化后接口平均响应时间≤500ms，APDEX指数≥0.95；
2. 逐步提升并发量级（20、50、100线程），开展峰值压测，测试系统真实的性能上限，为线上活动的服务器扩容提供精准数据支撑；
3. 针对核心抽奖接口开展专项长稳压测，验证系统在4小时以上持续高并发下的稳定性。

---

七、最终测试结论

1. 系统稳定性达标：本次压测全周期请求成功率100%，无服务宕机、无数据异常，系统基础架构与服务容错能力合格，可支撑常规业务场景的稳定运行。
2. 核心业务性能优异：登录、抽奖、活动/奖品管理等核心业务接口响应速度符合预期，平均响应均控制在100ms以内，性能冗余充足，可满足线上活动的核心业务需求。
3. 存在致命性能瓶颈：人员、奖品全量列表查询接口存在严重的慢查询问题，最大延迟超30秒，是系统最大的性能短板；若不完成优化，线上高并发场景下会出现接口超时、页面卡死，甚至数据库宕机的风险。
4. 上线建议：必须完成本文提出的P0级优化项，且复测达标后，方可上线运行；优化后的系统可稳定支撑线上抽奖活动的全业务场景，满足高峰期的高并发需求。