SSL密集场景必须按物理核数设置worker_processes，因SSL握手是CPU密集型操作，超配会导致上下文切换激增、缓存争用加剧、QPS下降30%以上；须配合CPU亲和绑定与ssl_session_cache等参数联动调优。
SSL握手密集型业务对CPU计算资源消耗显著，worker_processes 配置必须严格匹配物理核心数，不宜超配，更不能依赖逻辑核数盲目设高。
为什么SSL密集场景必须按物理核数设置？
SSL/TLS握手（尤其是RSA密钥交换或ECDSA签名验证）是典型的CPU密集型操作。每个worker进程在处理HTTPS请求时，需独立完成密钥协商、证书验证、会话密钥生成等步骤。若进程数超过物理核心数：
- Linux调度器频繁切换进程上下文，cs（context switch）值飙升，实测可导致QPS下降30%以上；
- 多个worker绑定到同一物理核的超线程逻辑CPU上，共享L1/L2缓存，引发缓存抖动与争用；
- master进程调度开销增加，反而削弱了Nginx主从模型的稳定性优势。
正确配置方式：物理核数 + CPU亲和绑定
以一台2路×12核（共24物理核）服务器为例：
- 查真实物理核数：
lscpu | grep -E "Core\(s\) per socket|Socket\(s\)"→ 得到 12 × 2 = 24； - Nginx配置写：
worker_processes 24;（不推荐auto，因部分容器/虚拟化环境无法准确识别物理拓扑）； - 强制绑定物理核：
worker_cpu_affinity auto;（Nginx ≥1.9.10，自动跳过HT对称核）或手动掩码（如24核需24组二进制位）； - 配套调高连接能力：
worker_connections 4096;，并确保worker_rlimit_nofile 131072;（≥ 24 × 4096）。
需要同步优化的关键项
仅调worker_processes远远不够，SSL密集型必须联动以下参数：
-
ssl_session_cache shared:SSL:10m;—— 复用会话减少完整握手次数； -
ssl_session_timeout 4h;—— 延长缓存有效期，降低复用成本； -
ssl_prefer_server_ciphers on;+ 合理精简ssl_ciphers列表 —— 避免客户端协商低效算法； -
use epoll;和multi_accept on;放入events块 —— 提升新连接接纳效率； - 系统层启用
net.core.somaxconn = 65535与fs.file-max = 2097152—— 防止内核级连接瓶颈。
压测验证要点
上线前务必用真实TLS流量压测，重点观察：
-
htop中各worker进程是否均匀占用不同物理核（非仅逻辑CPU）； -
vmstat 1中cs值是否稳定在每秒5000以下（超1万即存在严重调度压力）； -
openssl s_client -connect单连接握手耗时是否≤30ms（硬件加速正常应 - 使用
wrk -H "Connection: keep-alive" -s ssl.lua模拟复用连接，对比全握手与复用场景的QPS差异。
