nginx极限https吞吐量测试核心是精准复现tls负载并隔离加密瓶颈：需分层测量ssl/tls tps、https rps和加密吞吐率，使用wrk2或go-wrk等支持tls建模工具，覆盖高新建、高复用及混合场景，并同步监控cpu用户态占用、内核软中断、nginx握手成功率及系统资源限制。
测试 Nginx 在极限并发下的 HTTPS 加密吞吐量，核心是精准复现真实 TLS 负载压力，并隔离加密计算瓶颈。不能只压 HTTP 流量，必须让每请求都触发完整 TLS 握手或会话恢复，同时监控 CPU 加密运算、连接建立速率与有效吞吐三者的关联。
明确目标指标与压测类型
HTTPS 吞吐量不是单一数值，需分层测量：
- SSL/TLS Transactions Per Second (TPS)：每秒完成的 TLS 握手数（含 full handshake 和 session resumption），直接反映 CPU 加密能力瓶颈
- HTTPS Requests Per Second (RPS)：每秒成功返回 HTTP 响应的请求数（含 TLS + HTTP 处理），体现端到端服务能力
- Encrypted Throughput (MB/s)：单位时间传输的加密后字节数，关注大文件场景下 AES-GCM 硬件加速效果
-
Active TLS Handshakes：通过
/status接口中的accepts与handled差值，判断握手失败率（handled 表示 TLS 层丢弃）
选用支持 TLS 建模的压测工具
普通 HTTP 工具（如 ab）无法控制 TLS 行为，推荐以下组合：
-
wrk2（推荐）：支持
-H "Connection: close"强制每请求新建 TLS 连接，可精准测 full handshake TPS；配合--latency观察握手延迟毛刺 - go-wrk：原生支持 TLS 1.3、session ticket 控制，能分别测试“全新建连接”和“高复用连接”两种模式
-
custom Python + asyncio + ssl.SSLContext：用
ssl.OP_NO_TLSv1 | ssl.OP_NO_TLSv1_1强制协议，手动控制set_session复用逻辑，适合深度验证会话缓存策略 - 避免使用 siege 或旧版 ab：不支持 TLS 1.3、无法区分 handshake 类型，结果严重失真
构造贴近极限的压测场景
真实瓶颈常出现在特定组合下，需覆盖三类典型压力：
-
高新建连接型：每请求
curl -k --http1.1 https://host/ --max-time 1模式，禁用 keepalive，测单核 TPS 极限（如 TLSv1.2 RSA 2048 ≈ 150–500 次/秒/核） -
高复用连接型：wrk2 启动 1000 并发、keepalive=60s，观察
ssl_session_cache命中率是否 ≥90%，此时 RPS 应比新建型高 2–3 倍，CPU 占用却下降 60%+ -
混合负载型：80% 请求复用会话 + 20% 强制新握手（如随机加
curl -k --ciphers ECDHE-RSA-AES256-SHA），模拟真实用户行为，暴露 session ticket 同步或 OCSP stapling 延迟问题
配套监控必须同步开启
仅看 RPS 数值无意义，需实时采集四类数据：
-
CPU 细粒度：
top -p $(pgrep nginx) -H查看各 worker 线程 %us（用户态 OpenSSL 调用），若某线程持续 >90%，说明加密成为单点瓶颈 -
内核软中断：
watch -n1 'cat /proc/stat | grep ^soft'，si% >70% 表示网卡中断处理过载，需检查reuseport on和 RPS 配置 -
Nginx TLS 指标：访问
https://yourdomain.com/status（需配置在 443 server 块内），重点关注：
•handled / accepts比值 → 握手成功率
•Reading数值突增 → SSL_accept 阻塞堆积
•Waiting长期高位 → accept 队列积压或multi_accept配置不当 -
系统级支撑：确认
ulimit -n≥65535、net.core.somaxconn≥65535、worker_connections≥10240，否则“too many open files”会伪造出 TLS 性能问题
