压测报告

报告人：王芳

参与人：刘洋、李莉、陈静

压测日期：0000-00-00

环境：预发环境，数据量按六地一年估算

结论：40 QPS 通过，80 QPS 需先加索引

一、测试结论

本次压测对象是行政协同平台的会议室预订创建。预发在 25 QPS 和 40 QPS 两档达到发布标准：40 QPS 持续 15 分钟，P99 为 280 毫秒，错误率 0.04%。80 QPS 持续 10 分钟时 P99 升到 910 毫秒，错误率 1.6%，瓶颈在预订表按会议室和时段查冲突时的行锁。结论是：六地开放按 40 QPS 作为容量上限；若业务峰值要顶到 80 QPS，需先完成冲突查询索引并复测。

二、范围与环境

压测覆盖「创建预订」一条接口，包含空闲校验、写预订、更新缓存三步。预发为 2 台 4 核应用，数据库 1 主 1 从。预订表灌入 80 万行，用来模拟六个办公点运行一年后的数据量，生产当前实际约 1.8 万行。企业微信使用挡板，固定 30 毫秒返回成功。缓存为独立 Redis，与生产规格一致。

三、压测场景

1. 基准档：10 QPS 持续 10 分钟，确认环境和数据可用。
2. 目标档：25 QPS 持续 15 分钟，对应当前估算的六地合并峰值。
3. 保护档：40 QPS 持续 15 分钟，对应当下限流阈值。
4. 冲高档：80 QPS 持续 10 分钟，用来观察余量耗尽后的表现。

每档使用 2,000 个独立员工账号，每个账号最多成功 1 次，避免单人 10 秒 3 次的限流把结果挡掉。会议室按 72 间分布，与六地房间规划一致。王芳于 9月15日 14:00 至 16:10 完成四档，中间每档间隔 5 分钟。

四、结果数据

前三档没有出现双订。80 QPS 档产生 12 对时段重叠的预订，都发生在同一间会议室的同一 30 分钟上，应用日志里冲突查询耗时超过 700 毫秒。网关在四档中均未提前拒绝，说明结果反映的是服务本身，而不是限流截断。

五、瓶颈定位

李莉导出 80 QPS 档的慢日志，共 640 条，其中 71% 是按 room_id、book_date、start_min 查询后再加锁。该表目前只有 room_id 单列索引，日期和开始时间在存储引擎中过滤。应用 CPU 最高 48%，Redis 命中率 99%，这两处还有余量。刘洋据此把联合索引草案交给李莉，预发建索引后的抽查查询从 180 毫秒降到 12 毫秒，全量复测安排在索引进入预发的次日。

六、后续安排

1. 六地开放的预订限流维持 40 QPS，与本次通过水位一致，由陈静写入容量目标。
2. 李莉于 9月26日 21:40 在生产低峰创建联合索引，王芳于 9月27日复测 80 QPS。
3. 复测通过前，开放节奏按 40 QPS 封顶。若研发园首日峰值超过 15 QPS，周敏临时把全站阈值从 40 调到 30，并在群里说明恢复条件。