本文基于 AWS 环境下的 SSO 登录接口（/callback-sso）的真实压测数据，提供完整的测试环境配置、执行步骤和结果分析方法。

---

一、测试目标

• 验证 AWS SSO 登录接口在高并发场景下的稳定性
• 识别系统性能瓶颈（CPU/内存/网络）
• 确定生产环境的容量规划基准

---

二、测试环境配置

2.1 关键约束条件

• 无备份站点（No backup site）
• 无自动扩缩容（No autoscaler）
• 无 WAF 防护（No WAF）
• 直接测试服务端地址：
  通过内部服务地址发起请求（非 Public Endpoint），例如：
  POST https://login-int.example.com/callback-sso

2.2 架构说明

• 部署平台：AWS EKS（Kubernetes）
• 核心服务：
  • auth-service：身份认证服务（处理 /callback-sso 请求）
  • app-server：应用后端服务
  • api-gateway：API 网关（流量入口）
• 存储：Amazon RDS（MySQL）、ElastiCache（Redis）

2.3 基准资源配置

服务	Pod 数量	CPU 限制	内存限制
auth-service	2	500m	1024Mi
app-server	2	350m	512Mi

2.4 测试工具

• JMeter 5.4+：模拟服务端调用
• kubectl：监控 Pod 资源使用情况
• CloudWatch：收集 AWS 服务指标

---

三、测试步骤

步骤 1：准备测试脚本

创建 JMeter 测试计划（sso-stress-test.jmx）：

• 线程组：设置并发用户数（10/100/200/300/400）
• HTTPS 请求：

  POST https://login-int.example.com/callback-sso
  Content-Type: application/json
  Body: {"token": "test-token-${__threadNum}"}
  

• 监听器：聚合报告 + 响应时间图

步骤 2：执行压测

# 启动压测（持续 20 分钟）
jmeter -n -t sso-stress-test.jmx -l result.jtl -Jduration=1200

# 实时监控资源（另开终端）
kubectl top pods -n sso-prod --sort-by=cpu

步骤 3：收集指标

• 应用层：JMeter 聚合报告（响应时间、错误率、吞吐量）
• 基础设施：
  • kubectl top pods：CPU/内存使用率
  • CloudWatch：RDS 连接数、Redis 命中率

---

四、测试结果分析

4.1 基准测试数据

并发用户数	平均响应时间 (ms)	错误率	吞吐量 (req/s)	auth-service CPU	auth-service 内存
10	1163	0%	8.58	10%	115MiB
100	1339	0%	74.58	40%	150MiB
200	2544	0%	78.51	40%	200MiB
300	4125	3.18%	72.66	40%	500MiB
400	5867	3.86%	68.08	40%	390MiB

4.2 关键发现

1. 性能瓶颈

   • auth-service 是主要瓶颈（CPU 稳定在 40%，内存随并发线性增长）
   • app-server 资源占用几乎无变化

2. 错误分析

   • 错误类型：502 Bad Gateway、504 Gateway Timeout
   • 根本原因：网关超时（默认 60s），非应用层故障

3. 扩容效果验证
   将 auth-service 从 2 Pod 扩容到 4 Pod 后：

   • 400 并发下错误率降至 0%
   • 吞吐量提升 96%（78 → 153 req/s）

4.3 优化建议

• 容量规划：按 400 并发/4 Pod 配置 auth-service
• 网关调优：增加超时设置（read_timeout ≥ 10s）
• 发布验证：任何 auth-service 变更必须通过 200 并发压测

---

五、附录：关键配置参考

5.1 JMeter 线程组配置

参数	值
线程数	100
Ramp-Up 时间	60 秒
持续时间	1200 秒
循环次数	永远

5.2 API 网关超时配置

# gateway.yaml
services:
- name: auth-service
  read_timeout: 10000  # 10秒
  write_timeout: 10000
  connect_timeout: 3000