测试 nginx 高并发 https 压测 cpu 负载，核心是用 wrk 多线程模拟真实 tls 握手（需 -s ./ssl.lua），禁用本地回环，聚焦软中断、worker 进程不均及 ssl 函数热点，并同步调优 nginx 与系统 ssl 相关配置。
测试 Nginx 在高并发 HTTPS 压测下的 CPU 负载，核心是让压测真实触达 Nginx 的 SSL 处理路径，并同步采集细粒度、可归因的 CPU 使用数据，而非只看整体利用率。
用 wrk 模拟真实 HTTPS 并发压力
ab 工具在 HTTPS 场景下存在 TLS 握手开销大、单线程瓶颈明显的问题，不推荐用于高并发验证。必须使用支持多线程 + HTTP/1.1/2 + TLS 的 wrk：
- 命令示例：wrk -t8 -c2000 -d120s --latency -s ./ssl.lua https://nginx-ip/（-s ./ssl.lua 是关键，需自定义脚本启用完整 TLS 握手与证书校验）
- 并发连接数（-c）建议设为 worker_processes × worker_connections × 0.7，避免过早触发系统级限制
- 务必使用公网 IP 或局域网直连地址，禁用 127.0.0.1 —— 本地回环会绕过网络栈和部分 CPU 软中断路径，导致 CPU 负载失真
聚焦 SSL 相关 CPU 指标，不止看 top
HTTPS 压测中，CPU 瓶颈常集中在软中断（si）、上下文切换（cs）和 worker 进程调度不均，而非单纯的 user/system 时间：
- 实时运行 vmstat 1：重点关注 si（软中断）是否持续 >80%，若接近 100%，说明网卡中断或 SSL 解密占满单核
- 用 htop -p $(pgrep nginx) 查看每个 worker 进程的 CPU 占用，若某进程长期 >95% 而其余 worker_cpu_affinity 未生效或存在惊群
- 执行 cat /proc/interrupts | grep eth 确认网卡中断是否集中于单个 CPU；搭配 sudo irqbalance --debug 检查中断是否均衡分发
验证 Nginx SSL 处理是否真正成为 CPU 主要消耗者
很多“CPU 高”实际来自内核协议栈或后端服务拖累，需交叉排除：
- 开启 Nginx stub_status，访问
/nginx_status观察 Reading/Writing/Waiting 分布：若 Waiting 占比 >70%，说明连接堆积在 accept 队列或 SSL 握手阶段，可能受net.core.somaxconn或ssl_buffer_size限制 - 对比压测前后 perf top -p $(pgrep nginx) 输出：若
SSL_do_handshake、evp_cipher_do_cipher或sha256_block_data_order占比超 40%，即确认为 SSL 计算瓶颈 - 临时关闭 HTTPS 改用 HTTP 压测同流量：若 CPU 降幅 >60%，则原始高负载基本可归因为 TLS 处理
配套系统与 Nginx 关键配置检查
CPU 负载异常升高，往往源于配置与系统限制不匹配：
- worker_processes auto; 且 worker_cpu_affinity auto; 必须启用，否则多核无法并行处理 SSL 握手
- ssl_protocols TLSv1.2 TLSv1.3; 禁用 TLSv1.0/1.1 减少旧算法开销；优先启用 ssl_prefer_server_ciphers off; 让客户端选更优 cipher
- 系统层：确认
ulimit -n ≥ 65535，net.core.somaxconn = 65535，net.ipv4.tcp_fastopen = 3（加速 TLS 0-RTT）
