MFA压测核心是保障“认证路径真实耗时”和“高并发下一致性”，瓶颈多在密码学运算、状态同步、令牌校验及Redis/DB等后依赖，须用RPS建模、混合三类负载、紧盯P99延迟、双花防护、风控准召与后端饱和度。
多因素认证（MFA）服务的性能压测，不能简单套用通用Web接口压测方法。它的瓶颈往往不在CPU或带宽，而藏在密码学运算、会话状态同步、令牌校验链路和后端依赖（如Redis缓存、数据库、OTP生成器）里。一次靠谱的评估，必须围绕“认证路径真实耗时”和“高并发下一致性保障”两个核心展开。
明确MFA认证链路与关键节点
MFA请求通常走这样的路径：客户端提交凭证 → 网关路由 → 认证服务解析Token → 校验主凭据（如用户名/密码）→ 查询并校验第二因子（TOTP/HOTP/SMS/推送）→ 更新会话状态 → 返回结果。每个环节都可能成为短板：
- 密码学运算：TOTP/HOTP验证需实时计算哈希，高并发下SHA-1/SHA-256 CPU占用陡增；
- 状态存储读写：已使用的一次性密码需标记为“已消费”，依赖Redis原子操作（INCR/SETNX）或数据库行锁；
- 外部依赖延迟：若短信网关响应慢、推送服务超时重试，会导致整个认证流程阻塞；
- 会话同步开销：集群部署时，登录态需跨节点同步，若用Session复制而非共享存储，网络开销显著上升。
设计贴近真实场景的压测模型
避免只测“单点校验接口”，要还原用户完整登录动作。推荐采用RPS模式（而非纯并发数），因为MFA是短连接、强时效性操作，RPS更能反映单位时间处理能力：
- 用wrk或k6构造含完整Header、Cookie、X-CSRF-Token的请求流；
- 模拟三种典型负载：正常登录（主凭据+有效TOTP）、重试登录（主凭据正确+错误OTP，触发风控限流）、失效登录（过期TOTP或已使用码）；
- 按业务比例混合：例如85%正常、10%重试、5%失效，比100%成功请求更易暴露风控模块瓶颈。
重点监控与有效性指标
除了常规的QPS、平均响应时间、错误率，MFA压测必须盯住以下四项：
- P99认证延迟 ≤ 800ms：OTP类认证对用户体验敏感，P99超1秒即可能引发用户重复点击；
- 令牌消费一致性：压测中随机抽检1000个成功请求，确认对应TOTP码在Redis中确为EXPIRE+DEL，无“双花”或残留；
- 风控拦截准确率：在重试流量中，检查是否按策略触发滑动窗口限流（如5分钟内最多3次失败），且未误伤正常用户；
- 后端依赖饱和度：监控Redis的connected_clients、rejected_connections、latency；数据库连接池wait_count、active_count；短信通道调用量与配额余量。
识别真实瓶颈的实操建议
当QPS卡在某个阈值不再上升时，别急着加机器——先做三件事：
- 开启认证服务全链路追踪（如Jaeger），看耗时主要分布在“OTP校验”还是“DB查用户”还是“Redis SETNX”；
- 用perf record -g -p [pid]抓取热点函数，确认是否SHA256计算占CPU主导；
- 临时关闭风控模块再压一次，若QPS翻倍，说明限流逻辑本身成了瓶颈，需优化算法或拆分校验阶段。
