大促前的全站HTTPS性能压测，核心不是压出极限QPS，而是验证在真实流量冲击下，加密链路、证书协商和回源通道能否稳定扛住峰值。
很多团队用HTTP压测工具直接套HTTPS，结果一上大促就暴露TLS握手超时、证书链不完整、会话复用失效等问题，下面这套流程从目标拆解、工具选型到数据分析，按阶段推进。
大促前HTTPS压测怎么做？先分清瓶颈在哪
HTTPS和HTTP的最大区别在于多了一层TLS握手和加密传输,压测时，单用户请求的CPU消耗比HTTP高好几倍，尤其是ECDHE密钥交换和AES加解密环节，业内专家指出，同样配置下HTTPS的吞吐量往往只有HTTP的40%到60%，所以压测目标不能直接拿去年HTTP峰值乘系数，要先想清楚这层差异。
压测前需要把全站链路拆成四个环节：客户端到边缘节点、边缘节点到源站、源站应用处理、数据库与缓存，每个环节都可能有个瓶颈，很多大促故障不是后端扛不住，而是CDN回源时TLS重新握手导致源站连接数爆炸。
实操上,先做一次小规模探测性压测，比如用200并发持续5分钟，观察各环节的CPU、内存、连接数变化，如果边缘节点CPU先飙到80%以上，说明加密卸载做得不够；如果源站连接数猛增但CPU不高，多半是回源握手太频繁，这一步能让你在大促前找准优化方向，而不是盲目扩容。
压测目标怎么定？别只盯着QPS
QPS是结果指标,不是性能指标，大促场景下，更应该关注三个维度：
- 响应时间分位数：P95和P99特别重要，因为大促流量会放大长尾延迟，比如商品详情页接口，P99超过800毫秒，用户就会有卡顿感。
- 错误率：HTTPS压测中常见错误是握手超时、证书验证失败、连接重置，错误率控制在1%以内才算健康。
- 系统饱和度：观察CPU、内存、磁盘IO、TCP连接数、SSL会话缓存命中率，如果SSL会话缓存命中率低于90%，就需要加大缓存容量或调整超时时间。
目标是设定一个可接受的降级阈值，比如大促峰值预估10万QPS，压测时先压到5万，观察响应时间是否平稳，再逐步加压到12万，看系统在超负荷时的表现，重要的是记录下“从哪个并发数开始P99急剧上升”，这个拐点就是大促时的告警阈值。
HTTPS压测QPS上不去？问题可能出在TLS握手
很多团队反馈,同样一台机器，压HTTP能跑到5万QPS，改压HTTPS连1万都过不去，多数情况下，问题不在加解密性能，而在TLS握手的连接建立效率。
一次完整的TLS 1.2握手需要2个RTT，算上TCP三次握手就是5个RTT，在长连接场景下，这个开销被分摊了；但如果压测工具或客户端代码没有开启连接复用，每个请求都新建连接，QPS自然上不去。
针对这个问题,有几个优化方向：
- 启用TLS 1.3：将握手缩短到1个RTT，0-RTT模式甚至可以复用之前的会话，显著减少延迟。
- 配置会话复用：在Nginx或CDN层开启
ssl_session_cache，并设置合理的ssl_session_timeout（比如10分钟），压测时观察
ssl_session_cache_hit
- 开启OCSP Stapling：让服务端在握手时直接附带证书吊销状态，避免客户端额外请求OCSP服务器，减少一次连接。
- 检查证书链完整性：如果中间证书没配全，部分客户端会因证书验证失败而重新发起请求，导致大量握手重试。
建议压测前先手动用openssl s_client -connect 域名:443 -tls1_3验证一下协议和证书链，再用curl -w观察time_appconnect（TLS握手时间），如果平均握手时间超过30毫秒，就必须优化。
压测工具怎么选？真实场景模拟至关重要
工具选型决定压测结果的真实性,用过几种常见工具：
- wrk：适合快速测试单机HTTP/HTTPS性能，但默认不支持HTTP/2和复杂业务逻辑，只能简单测量吞吐。
- JMeter：支持HTTPS、HTTP/2、断言和分布式压测，但资源占用较高，单机并发有限，需要多台负载机。
- k6：脚本用JavaScript写，支持HTTPS和WebSocket，内置性能指标，适合CI/CD集成，最大的优点是能模拟用户think time和不同场景。
- Locust：基于Python，协程并发，适合模拟大规模用户但需要自己管理节点。
大促前压测,建议先用wrk快速摸清单机能力，再用k6或JMeter做场景化压测，比如模拟用户从点击按钮到完成下单的完整HTTPS请求序列，每个步骤之间有随机间隔，而不是所有线程同时猛刷一个接口，这样的结果才贴近真实流量。
压测机所在网络位置也很关键,如果压测机和服务端在同一内网，测出来的是纯应用性能；如果从公网压，能验证全国不同运营商线路的延迟和丢包率，大促前最好两种都测：内网测上限，公网测体验。
全站HTTPS性能优化方案：从边缘到源站逐层排查
全站HTTPS不是只给入口加证书就完事,边缘节点、回源链路、后端应用，每一层都可能成为性能瓶颈。
边缘层：卸载证书与连接复用
大部分流量到达CDN或负载均衡后就应该完成TLS卸载,把解密后的HTTP请求转发给源站，如果让源站自己处理TLS，压力会成倍增加，边缘层需要重点验证：
- 是否开启了HTTP/2，它支持多路复用，可以在一个连接上并发多个请求，减少连接数。
- 是否有连接复用到源站，避免每个客户端请求都回源建连。
- HSTS头是否正确设置，让浏览器强制使用HTTPS，减少明文请求。
回源层：避免多次TLS握手
边缘节点到源站之间,如果走的是HTTPS，一定要开启长连接，很多源站应用服务器默认没有配置keep-alive，导致每次回源都重新握手，行业共识认为，回源TLS握手成本占整体延迟的比例可能达到30%以上，优化方式是设置反向代理（如Nginx）到源站的连接池，并调整keepalive_timeout。
源站层：缓存与CPU优化
TLS解密会消耗大量CPU,尤其是RSA或ECDHE运算，如果源站CPU在压测中达到70%以上
，且大部分时间花在加解密上，就要考虑：
- 优化应用代码,减少不必要的动态请求，增加静态文件缓存。
- 调整SSL密码套件,优先使用
ECDHE-ECDSA-AES128-GCM-SHA256这类性能好的组合，禁用已知弱套件。 - 有条件的话,使用硬件加速卡或支持AES-NI指令集的服务器芯片，加解密性能可以提升好几倍。
大促压测工具选型：不同场景用不同武器
大促前通常需要跑三类压测：全链路压测、单接口压测、故障演练，这三类场景对工具的要求完全不同。
| 场景 | 推荐工具 | 核心关注点 |
|---|---|---|
| 单接口吞吐摸底 | wrk、ab | 最大QPS、平均延迟 |
| 多用户场景模拟 | k6、JMeter | P99延迟、错误率 |
| 全链路分布式压测 | JMeter + InfluxDB + Grafana | 系统资源联动、瓶颈定位 |
全链路压测时,压测请求要携带真实的证书校验逻辑，不能跳过SSL验证，因为有些工具默认忽略证书错误，测出来的结果和真实用户差异很大，要控制压测流量不污染线上数据，可以用影子表或独立压测环境。
分布式压测需要注意负载机本身的连接数限制,单台负载机默认文件描述符只有1024，跑高并发前要执行ulimit -n 65535并调整系统参数，否则，压测机先扛不住，结果会显示服务端性能很差，实际是压测机自己成为了瓶颈。
压测执行中的常见坑：证书过期与连接复用
大促前最怕的不是性能不够,而是证书过期，很多团队压测时才发现证书在第二天到期，导致大量握手失败，建议在压测计划中加入证书检查步骤：
- 用
openssl x509 -enddate -noout -in 证书文件查看到期时间。 - 用在线工具或脚本监控证书剩余天数,提前两周告警。
- 确认证书链中
CA Issuers的中间证书没有失效。
连接复用是另一个高频问题,压测时如果使用短连接，每秒钟会创建大量TCP连接，服务端可能会耗尽端口或内存，建议压测脚本中尽量复用连接，除非你要专门测试连接数爆炸的场景，测试连接数限制时，可以故意使用短连接，观察服务端的TIME_WAIT和ESTABLISHED状态变化。
还有一个坑是会话缓存不共享，多台源站服务器各自维护SSL会话缓存，会导致同一客户端在不同服务器间跳转时重新握手，如果架构里有多个Web节点，要确保会话缓存使用共享存储（如Redis）或启用一致的会话密钥。
压测数据怎么分析？不要被平均时延骗了
平均时延很容易掩盖问题,比如一个接口平均时延100毫秒，但P99可能已经到2秒，意味着有1%的请求遭遇毛刺，大促期间，这1%可能就是几十万用户，体验直接崩掉。
分析压测数据时,按顺序做这四件事：
- 看错误率趋势：错误率如果从0.01%突然上升到0.5%，说明系统开始不稳定，即使QPS还在增长，也要立即停止加压。
- 对比P50、P90、P99时延：如果P50和P90差距不大，但P99飙升，通常是某台机器开始异常或GC停顿，需要检查进程日志。
- 关联系统资源：把请求时延曲线和CPU、内存、网络IO曲线放在同一张图上，如果CPU上升的同时时延同步上升，说明计算成了瓶颈；如果CPU平稳但时延上升，可能是锁竞争或线程阻塞。
- 验证缓存命中率：HTTP缓存命中率低会导致大量请求回源，回源慢又会拖慢整体时延，用
cache_hit_ratio指标对比不同压测阶段的数据。
压测结束后,把“最后正常压力值”和“崩溃压力值”记录下来，比如在8万QPS时系统正常，到了10万QPS时错误率超过5%，大促时就把告警阈值设为7万，预留30%余量。
大促前HTTPS压测怎么规划时间？别最后一天才跑
压测不是一次性动作,应该拆成三轮：
- 第一轮（提前两周）：小规模探测，验证证书、协议、基础配置，暴露明显问题。
- 第二轮（提前一周）：全链路场景压测，模拟大促当天的流量模型，优化瓶颈点。
- 第三轮（提前两天）：演练故障场景，比如手动杀掉一台源站，观察负载均衡能否快速切换，SSL会话缓存是否失效。
每一轮压测后都要修复问题,并复测验证，如果等到大促前一天才压测，发现问题根本来不及处理。
全站HTTPS压测的关键就三句话：先分清瓶颈在TLS握手还是应用逻辑，再用合适的工具模拟真实用户，最后盯紧证书和连接复用这些细节。 大促前的稳定性不是靠临门一脚，而是靠提前多轮的验证和优化。
Q&A：大促前HTTPS压测常见问题解答
问：压测时发现HTTPS请求有大量握手失败，但HTTP请求正常，怎么排查？
先检查服务端证书是否过期或链不完整，用openssl s_client手动验证，再确认压测工具是否启用了SSL会话复用，如果没有，在工具中开启长连接，查看服务端ss -s，看SYN收到数和SYN重传数，如果重传率过高，可能是防攻击设备或防火墙限流了握手流量。
问：怎么判断性能瓶颈在SSL层还是在后端应用？
可以跑一组对比压测，一组用HTTPS协议，一组在应用层做加密后替换成HTTP，然后对比两者的QPS和响应时间，如果HTTPS的QPS比HTTP低一半以上，且CPU在SSL握手进程上占比高，说明瓶颈在SSL层，另一种方法是观察TLS握手阶段的time_appconnect，如果这个时间随着并发增加明显上升，而time_starttransfer（服务器响应时间）稳定，则瓶颈在握手。
问：压测工具本机性能对结果影响大吗？
很大，压测机如果CPU被打满，发出的请求本身就会延迟，导致误判服务端能力，使用wrk这类工具前，先运行htop观察压测机自身负载，确保单核CPU使用率不超过80%，如果压测机出现性能瓶颈，使用分布式压测方案，把负载分散到多台机器上。