接手过一个模拟项目X的网关压测K8s集群里跑的Ingress Nginx Controller默认配置装完8核节点压到4.8万QPS就开始“脸红脖子粗”P99延迟从3ms抖到80ms怎么看都配不上“Nginx性能好”的名声。后来花了两周逐步调参最终在同一台节点上稳定跑到10.2万QPSP99回到个位数毫秒。这篇内容就是那次调优过程的完整复盘适合正在做K8s网关、业务入口或者单纯想把Ingress Nginx单机性能榨干的SRE、运维和平台工程师参考。我会把瓶颈拆解、内核参数、核心ConfigMap配置、TLS成本控制、压测排障链路全部串起来讲每个改动都说明为什么改、改了会有什么代价。1. 先搞清楚瓶颈默认配置为什么连5万QPS都费劲1.1 从一次真实业务压测事故说起那次压测的触发点很普通大促前两周业务方要把支付回调、商品详情、订单查询三个核心接口的压测目标定到单机Ingress 10万QPS并且要求P99延迟不得超过20ms。当时我以为这不是什么难事Nginx本身就是主打高并发的软件10万QPS在裸Nginx上确实不是什么神话。结果压测一跑起来问题全冒出来了。默认的Ingress Nginx部署方式下一个Controller Pod里跑着Go控制面和Nginx worker进程。Go控制面负责监听K8s资源、生成nginx.conf、执行reload流量本身全走Nginx worker。我们当时用的是8核节点Pod的CPU limits也给了8结果压到4.8万QPS的时候Nginx worker CPU已经到86%但延迟直线上升压测端开始大量出现超时。更诡异的是用top看整体CPU并没有打满有一个核心的软中断softirq占用却长期在90%以上。用mpstat -P ALL 1一看明显是单核打满、其他核看戏。这个现象给了我第一个教训Ingress Nginx的性能瓶颈是分层的不能只盯着Nginx配置。CPU没有整体打满可能是软中断分配不均连接数上不去可能是内核参数不允许Nginx worker自己活得很累又可能是容器CPU throttle或者连接池配置不合理。1.2 三类瓶颈层容器资源、内核协议栈、Nginx配置我把这次调优涉及的瓶颈归纳成了三个层次后面所有的操作都围绕这三层展开第一层是容器资源层。Pod的CPU requests/limits设置不合理或者节点上多个Pod争抢CPU都可能导致CPU被cgroup限制Nginx worker明明想跑满却跑不上去。还有一个很多人忽略的点Nginx worker_processes默认是auto它读取的是容器cgroup的CPU配额而不是节点物理核数。如果你limits只写了2那Nginx在容器里只会看到2个可用CPU哪怕节点是64核它也只会起2个worker。第二层是内核协议栈层。Nginx再快数据也要从网卡经过内核协议栈到达用户态。somaxconn过小会导致accept队列溢出tcp_max_syn_backlog过小扛不住突发SYN文件描述符限制不够就会出现“too many open files”TIME_WAIT过多会耗尽本地端口这些都会在10万QPS级别被放大成致命问题。第三层才是Nginx配置层。包括worker进程数、单个worker的最大连接数、keepalive连接池、TLS会话缓存、超时与缓冲参数、日志与gzip的CPU开销等。这一层是“配置秘籍”的主体但前提是第一层和第二层已经打好底子否则Nginx配置调得再漂亮底层也接不住。1.3 Nginx很强不等于Controller很强两层架构的分工误区在K8s生态里有一个常见误解不少人以为Ingress Nginx性能不行质疑它是不是比裸Nginx弱很多。实际上Ingress Nginx仍然是Nginx/OpenResty在转发流量数据面性能底子没问题真正的差别在于它加了一层Go控制面负责监听、模板渲染、动态reload。控制面的负载非常轻瓶颈几乎不在它身上。但正因为有这层控制面很多人调优时把目光放在了Controller的Deployment副本数上试图通过多副本横向扩容来提升性能。这当然有效但如果你只扩容副本、不调Nginx配置每个副本还是会各自浪费资源。反过来如果你把单副本的Nginx配置调好了多副本只是纵向扩容的补充而不是性能差的救命稻草。我的目标很明确先把单副本、单节点的纵向性能压到10万QPS再谈副本扩容。这条路走通之后多副本自然就变得很从容了。2. 打地基节点、内核与容器的三层准备2.1 网卡多队列与软中断分散CPU不被中断抢占前面提到的那次压测第一眼看到的现象是单核softirq打满。这里解释一下为什么网卡收到数据包后网卡驱动会在内存中填充数据然后通过硬中断通知CPU处理。如果网卡队列只有一个或者中断没有均匀分发到多个CPU那么所有收包软中断都会压在一个CPU上。8个Nginx worker别的没事干就一个核在疯狂处理软中断QPS自然上不去。解决思路是让网卡多队列和CPU软中断尽量分散。在物理机上用ethtool -l eth0可以看到网卡当前的队列数再用ethtool -L eth0 combined 16把队列数设置成16同时配合irqbalance服务把中断号均匀绑定到不同CPU。云环境下的虚拟网卡不一定允许这些操作但至少应该在压测前确认网卡队列支持情况。这一步做完之后的验证方法很直观再跑一次mpstat -P ALL 1软中断应该均匀散布在多个核上而不是集中在一两个核。我当时修完这一项QPS直接从4.8万涨到了5.8万还没动任何Nginx配置就涨了20%。很多人在默认配置下压测遇到瓶颈第一反应就是加副本其实很有可能是软中断分配不均这种底层问题。2.2 内核参数清单连接数的物理上限第二个要解决的是内核协议栈的承载上限。K8s节点的sysctl默认值通常比较保守不适合高并发网关场景。以下是我在压测节点上实际改过的一组参数列成表格供参考参数默认值常见范围推荐值网关场景作用net.core.somaxconn409665535Nginx listen队列长度上限过小会丢连接net.ipv4.tcp_max_syn_backlog1024或204865535半连接队列上限抗突发SYN洪峰net.core.netdev_max_backlog100065535网卡驱动队列积压上限fs.file-max较小2097152或更高全系统文件描述符上限net.ipv4.ip_local_port_range32768-609991024-65535本机发起连接的源端口范围net.ipv4.tcp_tw_reuse01允许复用TIME_WAIT中的连接仅出站连接net.ipv4.tcp_fin_timeout6030缩短TIME_WAIT进入回收的等待时间这里要特别说明两点。第一net.ipv4.tcp_tw_reuse只对Nginx作为客户端去连接后端服务时有效因为TIME_WAIT是主动关闭连接的一方产生的。Nginx转发请求后主动关闭上游连接才会产生TIME_WAIT这时候tcp_tw_reuse才能发挥作用。如果后端是短连接且QPS很高每个请求都会产生一个TIME_WAIT不处理的话源端口很快就耗尽了。第二tcp_tw_reuse在NAT场景下要谨慎开启因为复用连接时可能会出现序列号不一致的问题。K8s里如果后端Pod通过NodePort暴露流量经过了NAT就需要评估风险。我的实际做法是先开启观察一段时间是否有连接错乱没有就保留有问题就改回0靠调大ip_local_port_range来缓解端口耗尽。修改sysctl的标准操作是写个/etc/sysctl.d/99-ingress.conf然后执行sysctl --system。注意这需要节点级权限如果用的是托管集群可能要联系平台侧调整。2.3 容器资源配额limits不是越大越好也不是越小越省接着是Controller Pod自身的资源设置。我见过很多人把Controller的limits写得特别小觉得Ingress路由很轻量也见过有人直接把limits写满整个节点结果其他Pod没地方跑。这两者都极端了。Ingress Nginx的Pod资源配额核心是CPU。我们的实测数据是8核CPU、8GiB内存的limits足够支撑10万QPS的转发常见TLS负载。如果你的limits小于4核建议先提到4或8再压测否则后续调Nginx参数时很难判断性能瓶颈到底在Nginx配置还是容器CPU被限制。一个很容易踩的坑是CPU throttle。K8s的CPU limits用的是CFS配额Pod的CPU使用率一旦触及limits就会被强制节流throttle表现为延迟毛刺、P99抖动但top看到的CPU占用可能还在50%-70%。我当时就遇到过limits设4核压测时Nginx worker CPU平均只有60%但P99从8ms突然飙到40ms后来查/sys/fs/cgroup/cpu.stat发现throttled_time非常大才意识到是CPU被节流了。所以压测时不要只看top要额外注意cat /sys/fs/cgroup/cpu.stat | grep throttled如果nr_throttled一直在增长说明容器CPU已经被卡住了。要么把limits调大要么把压测目标分摊到更多副本上。对于10万QPS目标我最终用的是requests4、limits8既保证了调度时不轻易超卖又给瞬时流量峰值留了余量。3. 核心ConfigMap调优一条一条讲清楚为什么要改3.1 worker-processes与max-worker-connections的配合公式Ingress Nginx的全局配置集中在ConfigMap里默认值覆盖了最基本的可用性但性能参数普遍偏保守。先说两个最核心的worker-processes和max-worker-connections。worker-processes控制Nginx worker进程数量。默认是auto前面说过它会读容器CPU配额。如果你确定节点物理核数是8或者16我建议直接显式写数字不要依赖auto。一个常见的经验公式是worker-processes min(节点物理核数, 16)为什么不能无脑等于核数因为worker进程太多会造成进程频繁切换CPU上下文切换开销反而拉低吞吐。8核就写816核可以写8或12超过16之后收益很小。我压测的8核节点写的就是8。max-worker-connections是单个worker进程能同时维持的最大连接数。这个参数很多人直接给65535然后就不管了。但真正合理的设定依赖你对并发连接数的估算并发连接数 ≈ QPS × 平均响应时间 客户端长连接保有量 上游keepalive连接数举个例子QPS10万Nginx转发请求到后端并返回的平均耗时是2ms那么瞬时在途请求大约是100000×0.002200个。这部分不大大头在keepalive长连接上。如果客户端开启HTTP长连接且并发连接数高达几万每个worker都要分摊一部分所以max-worker-connections设成65535、甚至更高都合理。注意Nginx本身还受文件描述符限制系统层要同步调大fs.file-max和容器进程的ulimit。对应ConfigMap片段data: worker-processes: 8 max-worker-connections: 65535改完以后执行kubectl rollout restart deployment/nginx-ingress-controller或者等待自动reload。验证方法看Nginx状态页curl -s http://127.0.0.1:10246/nginx_status观察Active connections和Reading/Writing等数值看是否随压测压力同步变化。3.2 全链路keepalive不只调一个客户端超时很多人都知道要在Ingress上开启keep-alive但容易漏掉上游连接池这一环。Ingress Nginx转发到后端服务时如果每次请求都新建TCP连接10万QPS下会产生海量的TCP握手和TIME_WAIT压力全部转嫁到内核协议栈。所以全链路keepalive至少包含三段第一段是客户端到Ingress Nginx的keepalive。ConfigMap里对应两个参数keep-alive-requests表示单个客户端长连接最多能复用的请求数keep-alive-timeout表示空闲连接保留时长。默认值通常够用但在高并发下建议把keep-alive-requests从默认提升到10000keep-alive-timeout保持60到75秒即可。第二段是Ingress Nginx到后端的upstream keepalive。这个是关键对应三个参数upstream-keepalive-connections每个upstream保留的空闲长连接数默认值偏小我调到了2048upstream-keepalive-requests单个上游连接最多复用的请求数默认1000我调到10000upstream-keepalive-timeout上游空闲连接保留时间默认30秒左右可以调到60秒顺带说一句upstream-keepalive-connections并不是越大越好因为保留的长连接也是资源。它需要同时覆盖后端Pod数量和后端支持的最大连接数。如果后端服务本身连接数上限很低你把Ingress侧调得很大也没有意义反而增加Nginx和后端的负担。第三段是HTTP/2多路复用。如果客户端支持HTTP/2一个TCP连接上可以同时跑多个请求这会显著减少客户端连接数量。ConfigMap里enable-http2默认是true保持即可。3.3 超时、缓冲与请求体隐性开销处理的取舍超时和缓冲参数是调优时最容易“抄错”的一类因为每个人的业务场景不同。我在这次10万QPS压测里用到的几个核心参数和理由放在下面这张表里参数推荐值原因proxy-connect-timeout10后端建连超时太长会在后端异常时卡住workerproxy-read-timeout60等待后端响应的超时按业务最慢接口的P99设计proxy-send-timeout60后端读取请求体的超时client-header-buffer-size16k默认通常较小请求头复杂时容易触发多余缓冲分配large-client-header-buffers4 32k与上面配合减少大请求头场景下的临时缓冲频繁分配client-body-buffer-size1m请求体缓冲设太大容易内存浪费设太小会触发临时文件IO这里要强调的是全部照抄我的值并不一定适合你的业务。比如proxy-read-timeout我做压测的接口都是几十毫秒返回的60秒只是兜底如果你的业务里有慢接口这个值需要单独调大否则会出现偶发504。proxy-buffering也值得单独说说。默认开启时Nginx会把后端响应缓冲到内存再发给客户端这对性能有正向帮助因为Nginx可以快速释放后端连接。但如果你跑的是超大响应体或流式接口缓冲反而会占用内存和延迟可以按Ingress annotation单独关闭不建议全局关。3.4 日志与压缩高频IO与CPU的第一降耗点在10万QPS量级日志和压缩的开销会被放大得很夸张。默认的log-format-upstream会把大量字段拼成一行每个请求都写一次磁盘IO和CPU字符串处理都是额外成本。而gzip每压缩一个响应都会吃掉CPU周期。这次压测里我做的第一个改动是关闭access logdata: disable-access-log: true直接在ConfigMap里禁用压测日志完全丢掉QPS提升非常明显。不过生产环境不建议长期全关因为排障需要访问日志。折中的方案是用更精简的log-format-upstream替代默认格式只记录时间、状态码、请求路径、上游耗时并且让日志走标准输出到容器日志收集器不直接写本地磁盘。压缩方面gzip默认开启且级别偏高我压测时直接把gzip-level降到了1并把gzip-types限制在text/css、application/javascript等少数文本类型图片、视频等已经压缩过的内容不做重复压缩。如果环境支持可以开启enable-brotli: trueBrotli在相同压缩比下CPU开销在某些场景比gzip更可控但也要实测对比不能无脑开。还有一个小细节动态压缩对高频接口性价比很低因为大部分响应体的内容可能都是可预测模板。更好的方案是在业务侧做静态压缩Ingress直接透传CPU开销几乎为零。4. TLS成本控制目标10万QPS必须跨过的第二道坎4.1 一次握手实际要消耗多少CPUTLS是性能压测中最容易低估的杀手。一次完整的TLS握手尤其是ECDHE密钥交换需要执行椭圆曲线点乘等非对称计算。虽然现在CPU都支持AES-NI等硬件加速但握手本身的计算开销依然远高于普通HTTP请求转发。我做过一个简单对照实验同一个8核节点、同样的配置纯HTTP转发能跑到9万QPS左右一旦全部走HTTPS新连接握手QPS会掉到不到一半。原因很直观每个新连接进来都要做一次握手握手消耗的CPU可能是普通转发请求的5到10倍。如果10万QPS全是新TLS连接CPU直接被打爆Nginx配置怎么调都救不回来。所以TLS调优的核心思路不是让握手更快而是尽量少握手、复用会话。4.2 会话缓存与会话复用的正确开启姿势Nginx侧需要开启TLS会话缓存让一定时间内复用相同会话的客户端免去完整握手。ConfigMap中相关的参数是ssl-session-cache: true开启会话缓存ssl-session-cache-size: 50m缓存容量默认10m压测中我调到了50mssl-session-timeout: 30m缓存有效期默认较短针对高复用连接可以放宽到30分钟ssl-buffer-size: 16k握手时发送的缓冲大小开启后客户端如果支持TLS Session ID或Session TicketTLS握手的第二次请求就能走简化握手CPU开销大幅下降。但问题在于客户端不一定每次都复用会话很多压测工具默认也不会复用TLS会话。比如用wrk压HTTPS时如果脚本里不带session复用逻辑测出来的就是最坏情况性能数据会很难看。这并不意味着生产环境一样差你要看真实客户端的TLS复用率。用h2load压HTTP/2时它会主动复用TLS会话测出来的数据更接近真实浏览器场景。生产环境建议通过监控TLS握手速率来确认会话复用率如果握手速率过高大概率是客户端每次请求都新建连接这时候要考虑调大保活时间和会话缓存或者推动客户端接入长连接。4.3 密码套件与算法选择性能和安全的平衡密码套件的选择也会影响CPU占用。旧版本的Nginx配置可能还带着ECDHE-RSA-AES256-GCM-SHA384这类强套件但它不是性价比最高的。在兼顾安全和性能的前提下我这次使用的是以下推荐套件配置ssl-protocols TLSv1.2 TLSv1.3; ssl-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; ssl-prefer-server-ciphers on;优先顺序是AES128-GCM比AES256快一些安全性在绝大多数业务场景足够。TLS 1.3默认使用更强且更快的握手一定要放到支持的协议范围里。全套配置在ConfigMap里可以直接通过ssl-ciphers和ssl-protocols设置。这里还要注意证书本身的性能使用ECDSA证书比RSA证书握手更快因为ECDSA签名体积小、验证开销低但证书签发链支持情况需要评估。如果业务方已经用了某个公开CA的RSA证书贸然更换成本高可以在需要极致性能的边缘场景单独给新证书或者把证书转到前置LB处理。4.4 该不该把TLS卸载到前面的负载均衡器聊到这里很多人会问既然TLS这么吃CPU那干脆把证书放在Ingress前面的负载均衡器上让LB做TLS卸载Ingress只处理明文HTTP是不是更好这个方案确实能显著降低Ingress Nginx的CPU负担。如果你的LB支持TLS终止并且已经把证书管理、自动续期做得很成熟那卸载到LB往往比在Nginx里做更省事。尤其是全站HTTP/2和高并发长连接场景LB承担的握手量可能成为新的瓶颈但那属于LB的扩展能力问题不管Ingress的事了。但卸载TLS也有代价一是LB到Ingress之间的链路如果是集群内部明文HTTP需要确保网络隔离可信二是Ingress侧拿不到加密连接信息有些基于TLS特征的限流或安全策略会失效三是排查问题时链路跳数变多。我的建议是如果Ingress就是最终网关且节点CPU可控保留TLS在Ingress做并调好会话复用如果后端Ingress已经需要承受大量TLS握手且CPU打满卸载到LB是合理选择。这两种方案没有绝对的对错核心是明确你的瓶颈到底在哪一层。5. 从5万到10万一轮完整压测与排障记录5.1 压测工具选型与压测机本身的问题要做10万QPS的压测工具选错了会闹笑话。我这次用的组合是wrk、h2load和vegeta各有分工wrk主要压HTTP/1.1场景支持多线程和连接数控制简单高效适合打纯HTTP和HTTPSHTTPS记得确认会话复用行为h2load压HTTP/2多路复用的首选能一次建立大量HTTP/2连接模拟真实浏览器和移动端长连接场景vegeta适合恒定压力长时间压测结果统计做得比较完善我用来做10分钟稳定性验证压测机本身也容易成为瓶颈。很多人在压测机上没调内核参数压到5万QPS时压测机自己的文件描述符或者端口先不够了。比如wrk默认每个线程创建大量连接Linux默认的ulimit -n只有1024不调大根本压不动。压测机至少需要把fs.file-max、net.ipv4.ip_local_port_range同步调大再用多台压测机对目标打流量避免单台压测机自己先被拖垮。如果你只有一台8核压测机还在同一台机器上跑压测工具和监控脚本那压测数据的可信度就打折扣了。我给的建议是压测机至少2台每台4核以上压测工具和mpstat、ss这些监控命令不要和目标Ingress节点混跑。5.2 第一轮压测CPU没用满但QPS上不去的怪事进入正题。第一次调整完软中断、内核参数和前面列出的ConfigMap配置后我满怀期待地开跑结果QPS卡在7.2万左右上不去了。top显示Nginx worker CPU总共才50%8个核里有两个偏高、其他不活跃。CPU没顶满QPS却先见顶这种“资源没用满但吞吐卡死”的情况最容易让人困惑。我当时的排查链路是这样的这条链路也值得记录第一步先用mpstat -P ALL 1看CPU分布。这时候发现硬中断和软中断已经均匀了问题不在中断了。但同时注意到有两个CPU的%sys特别高说明内核态在大量干活。第二步用ss -s和ss -nt state time-wait看连接状态。结果显示Time-Wait连接数量非常多每秒新建连接数量接近20万有些异常。这背后是wrk压测时没有开启keepalive复用导致每个请求都是新建TCP连接。这既是压测方法问题也是一个直观的信号真实业务如果也这样高频新建连接内核协议栈压力极大。第三步用dmesg看内核日志发现大量nf_conntrack表满的报错。K8s节点上conntrack是一个常见的隐藏限制默认表大小通常只有几十万条高连接场景下很容易满了丢包。这一步的真实命中比我想象中来得快。排障动作分两步走压测端wrk加-H Connection: keep-alive并限制并发连接数在一个合理区间降低新建连接速率节点上调大conntrack表和桶大小sysctl -w net.netfilter.nf_conntrack_max2097152 sysctl -w net.netfilter.nf_conntrack_buckets524288顺带说一下K8s很多组件都依赖conntrack调大前要确认安全别把节点内存打爆。这次调整后QPS直接从7.2万跳到9.1万问题的根源根本不是Nginx配置而是压测方法和连接跟踪能力。5.3 第二轮压测QPS上去了P99却开始抖动到了9.1万QPS离目标只剩一小步但P99延迟开始变得不稳定。10分钟内P99在7ms和35ms之间来回跳明显有周期性抖动。我一度怀疑是后端服务扛不住但通过后端监控看上游的P99一直在3ms以内问题还是出在Ingress这一层。这次我重点排查了两个点。第一是容器CPU throttle。前面提到过CPU limits8时如果瞬时突发流量超过8核cgroup会强制节流表现为P99抖动。用cat /sys/fs/cgroup/cpu.stat一看确实有nr_throttled增长。这说明8核在突发流量下已经有点紧张了光是调大limits不现实因为节点总共就那些核更好的思路是降低瞬时突发度比如在压测时控制并发连接增长速率让压力不是一次性涌进来。实际生产中这对应的是真实流量模型中突发尖峰的处理我会在模块末尾再说。第二是Nginx worker之间锁竞争。高并发下如果多个worker频繁争用共享锁也会出现CPU没打满但P99抖动的现象。用perf top看了内核热点确实看到了spinlock相关的符号占比不低。这个问题的根源之一是worker进程太多或连接分配不均尝试把worker-processes从8降到6后P99抖动有所缓解但总QPS下降了一点说明8个worker还是必要的。后来我没有强行压worker数而是通过开启HTTP/2多路复用来降低总连接数让每个worker的单位连接处理效率更高。最终P99回到了个位数毫秒。5.4 最终结果与调优前后对照最终的配置跑通后我用三台压测机同时打这台Ingress连续10分钟压力测试数据如下指标默认配置调优前调优后最终值单机QPS48,000102,000P99延迟21ms8msCPU整体占用72%68%软中断单核最大占用95%18%每秒新建TCP连接数约11万约2.1万后端P99延迟3ms3ms这份数据只是我这次压测环境下的结果不代表所有节点都能复现一模一样的数字。但它至少说明了一个问题10万QPS不是靠某一个单一配置项魔法般达成的而是底层中断分散、内核参数、Nginx keepalive链路、TLS会话复用、压测方法层层叠加的结果。每一个单点的提升都有限合在一起才冲过10万线。6. 结束语关于配置秘籍我想再提醒几件事这套配置跑通之后我在团队内部把ConfigMap固化成了标准模板后来其他业务接入时也直接复用。但有几句话我必须在最后单独拎出来说。第一这套调优默认你的后端响应足够快。如果后端接口P99本身就是200ms那Ingress再强的配置也只是把排队问题隐藏在后端QPS天花板会由上游决定你在Ingress侧看到的不再是性能瓶颈而是超时和排队积压。第二线上环境建议在10万QPS目标上留足余量。我压测达到10万QPS时CPU整体已经接近68%如果再叠加突发流量、日志收集、故障恢复等真实因素单机长期扛满10万是很危险的。实际容量规划建议按6到7万单机预留超出部分用副本横向扩容。第三每次改ConfigMap之后不要只看QPS有没有涨要看错误率和P99有没有恶化。Nginx的server-snippet、http-snippet这类自定义配置很容易改坏全局线上尽量少用。最后分享一个实用小技巧压测结束后把ConfigMap里每一项改动的记录和当时的QPS、P99对应起来形成一张自己的调参对照表。不同业务对延迟和吞吐的敏感度不一样我的“秘籍”只能作为起点真正属于你的配置需要用自己的流量模型反复压出来。 
长河君 · 2026/10/23 6:54:39 · 阅读 1.2k 从4.8万到10万QPS：K8s Ingress Nginx网关压测调优全复盘
接手过一个模拟项目X的网关压测K8s集群里跑的Ingress Nginx Controller默认配置装完8核节点压到4.8万QPS就开始“脸红脖子粗”P99延迟从3ms抖到80ms怎么看都配不上“Nginx性能好”的名声。后来花了两周逐步调参最终在同一台节点上稳定跑到10.2万QPSP99回到个位数毫秒。这篇内容就是那次调优过程的完整复盘适合正在做K8s网关、业务入口或者单纯想把Ingress Nginx单机性能榨干的SRE、运维和平台工程师参考。我会把瓶颈拆解、内核参数、核心ConfigMap配置、TLS成本控制、压测排障链路全部串起来讲每个改动都说明为什么改、改了会有什么代价。1. 先搞清楚瓶颈默认配置为什么连5万QPS都费劲1.1 从一次真实业务压测事故说起那次压测的触发点很普通大促前两周业务方要把支付回调、商品详情、订单查询三个核心接口的压测目标定到单机Ingress 10万QPS并且要求P99延迟不得超过20ms。当时我以为这不是什么难事Nginx本身就是主打高并发的软件10万QPS在裸Nginx上确实不是什么神话。结果压测一跑起来问题全冒出来了。默认的Ingress Nginx部署方式下一个Controller Pod里跑着Go控制面和Nginx worker进程。Go控制面负责监听K8s资源、生成nginx.conf、执行reload流量本身全走Nginx worker。我们当时用的是8核节点Pod的CPU limits也给了8结果压到4.8万QPS的时候Nginx worker CPU已经到86%但延迟直线上升压测端开始大量出现超时。更诡异的是用top看整体CPU并没有打满有一个核心的软中断softirq占用却长期在90%以上。用mpstat -P ALL 1一看明显是单核打满、其他核看戏。这个现象给了我第一个教训Ingress Nginx的性能瓶颈是分层的不能只盯着Nginx配置。CPU没有整体打满可能是软中断分配不均连接数上不去可能是内核参数不允许Nginx worker自己活得很累又可能是容器CPU throttle或者连接池配置不合理。1.2 三类瓶颈层容器资源、内核协议栈、Nginx配置我把这次调优涉及的瓶颈归纳成了三个层次后面所有的操作都围绕这三层展开第一层是容器资源层。Pod的CPU requests/limits设置不合理或者节点上多个Pod争抢CPU都可能导致CPU被cgroup限制Nginx worker明明想跑满却跑不上去。还有一个很多人忽略的点Nginx worker_processes默认是auto它读取的是容器cgroup的CPU配额而不是节点物理核数。如果你limits只写了2那Nginx在容器里只会看到2个可用CPU哪怕节点是64核它也只会起2个worker。第二层是内核协议栈层。Nginx再快数据也要从网卡经过内核协议栈到达用户态。somaxconn过小会导致accept队列溢出tcp_max_syn_backlog过小扛不住突发SYN文件描述符限制不够就会出现“too many open files”TIME_WAIT过多会耗尽本地端口这些都会在10万QPS级别被放大成致命问题。第三层才是Nginx配置层。包括worker进程数、单个worker的最大连接数、keepalive连接池、TLS会话缓存、超时与缓冲参数、日志与gzip的CPU开销等。这一层是“配置秘籍”的主体但前提是第一层和第二层已经打好底子否则Nginx配置调得再漂亮底层也接不住。1.3 Nginx很强不等于Controller很强两层架构的分工误区在K8s生态里有一个常见误解不少人以为Ingress Nginx性能不行质疑它是不是比裸Nginx弱很多。实际上Ingress Nginx仍然是Nginx/OpenResty在转发流量数据面性能底子没问题真正的差别在于它加了一层Go控制面负责监听、模板渲染、动态reload。控制面的负载非常轻瓶颈几乎不在它身上。但正因为有这层控制面很多人调优时把目光放在了Controller的Deployment副本数上试图通过多副本横向扩容来提升性能。这当然有效但如果你只扩容副本、不调Nginx配置每个副本还是会各自浪费资源。反过来如果你把单副本的Nginx配置调好了多副本只是纵向扩容的补充而不是性能差的救命稻草。我的目标很明确先把单副本、单节点的纵向性能压到10万QPS再谈副本扩容。这条路走通之后多副本自然就变得很从容了。2. 打地基节点、内核与容器的三层准备2.1 网卡多队列与软中断分散CPU不被中断抢占前面提到的那次压测第一眼看到的现象是单核softirq打满。这里解释一下为什么网卡收到数据包后网卡驱动会在内存中填充数据然后通过硬中断通知CPU处理。如果网卡队列只有一个或者中断没有均匀分发到多个CPU那么所有收包软中断都会压在一个CPU上。8个Nginx worker别的没事干就一个核在疯狂处理软中断QPS自然上不去。解决思路是让网卡多队列和CPU软中断尽量分散。在物理机上用ethtool -l eth0可以看到网卡当前的队列数再用ethtool -L eth0 combined 16把队列数设置成16同时配合irqbalance服务把中断号均匀绑定到不同CPU。云环境下的虚拟网卡不一定允许这些操作但至少应该在压测前确认网卡队列支持情况。这一步做完之后的验证方法很直观再跑一次mpstat -P ALL 1软中断应该均匀散布在多个核上而不是集中在一两个核。我当时修完这一项QPS直接从4.8万涨到了5.8万还没动任何Nginx配置就涨了20%。很多人在默认配置下压测遇到瓶颈第一反应就是加副本其实很有可能是软中断分配不均这种底层问题。2.2 内核参数清单连接数的物理上限第二个要解决的是内核协议栈的承载上限。K8s节点的sysctl默认值通常比较保守不适合高并发网关场景。以下是我在压测节点上实际改过的一组参数列成表格供参考参数默认值常见范围推荐值网关场景作用net.core.somaxconn409665535Nginx listen队列长度上限过小会丢连接net.ipv4.tcp_max_syn_backlog1024或204865535半连接队列上限抗突发SYN洪峰net.core.netdev_max_backlog100065535网卡驱动队列积压上限fs.file-max较小2097152或更高全系统文件描述符上限net.ipv4.ip_local_port_range32768-609991024-65535本机发起连接的源端口范围net.ipv4.tcp_tw_reuse01允许复用TIME_WAIT中的连接仅出站连接net.ipv4.tcp_fin_timeout6030缩短TIME_WAIT进入回收的等待时间这里要特别说明两点。第一net.ipv4.tcp_tw_reuse只对Nginx作为客户端去连接后端服务时有效因为TIME_WAIT是主动关闭连接的一方产生的。Nginx转发请求后主动关闭上游连接才会产生TIME_WAIT这时候tcp_tw_reuse才能发挥作用。如果后端是短连接且QPS很高每个请求都会产生一个TIME_WAIT不处理的话源端口很快就耗尽了。第二tcp_tw_reuse在NAT场景下要谨慎开启因为复用连接时可能会出现序列号不一致的问题。K8s里如果后端Pod通过NodePort暴露流量经过了NAT就需要评估风险。我的实际做法是先开启观察一段时间是否有连接错乱没有就保留有问题就改回0靠调大ip_local_port_range来缓解端口耗尽。修改sysctl的标准操作是写个/etc/sysctl.d/99-ingress.conf然后执行sysctl --system。注意这需要节点级权限如果用的是托管集群可能要联系平台侧调整。2.3 容器资源配额limits不是越大越好也不是越小越省接着是Controller Pod自身的资源设置。我见过很多人把Controller的limits写得特别小觉得Ingress路由很轻量也见过有人直接把limits写满整个节点结果其他Pod没地方跑。这两者都极端了。Ingress Nginx的Pod资源配额核心是CPU。我们的实测数据是8核CPU、8GiB内存的limits足够支撑10万QPS的转发常见TLS负载。如果你的limits小于4核建议先提到4或8再压测否则后续调Nginx参数时很难判断性能瓶颈到底在Nginx配置还是容器CPU被限制。一个很容易踩的坑是CPU throttle。K8s的CPU limits用的是CFS配额Pod的CPU使用率一旦触及limits就会被强制节流throttle表现为延迟毛刺、P99抖动但top看到的CPU占用可能还在50%-70%。我当时就遇到过limits设4核压测时Nginx worker CPU平均只有60%但P99从8ms突然飙到40ms后来查/sys/fs/cgroup/cpu.stat发现throttled_time非常大才意识到是CPU被节流了。所以压测时不要只看top要额外注意cat /sys/fs/cgroup/cpu.stat | grep throttled如果nr_throttled一直在增长说明容器CPU已经被卡住了。要么把limits调大要么把压测目标分摊到更多副本上。对于10万QPS目标我最终用的是requests4、limits8既保证了调度时不轻易超卖又给瞬时流量峰值留了余量。3. 核心ConfigMap调优一条一条讲清楚为什么要改3.1 worker-processes与max-worker-connections的配合公式Ingress Nginx的全局配置集中在ConfigMap里默认值覆盖了最基本的可用性但性能参数普遍偏保守。先说两个最核心的worker-processes和max-worker-connections。worker-processes控制Nginx worker进程数量。默认是auto前面说过它会读容器CPU配额。如果你确定节点物理核数是8或者16我建议直接显式写数字不要依赖auto。一个常见的经验公式是worker-processes min(节点物理核数, 16)为什么不能无脑等于核数因为worker进程太多会造成进程频繁切换CPU上下文切换开销反而拉低吞吐。8核就写816核可以写8或12超过16之后收益很小。我压测的8核节点写的就是8。max-worker-connections是单个worker进程能同时维持的最大连接数。这个参数很多人直接给65535然后就不管了。但真正合理的设定依赖你对并发连接数的估算并发连接数 ≈ QPS × 平均响应时间 客户端长连接保有量 上游keepalive连接数举个例子QPS10万Nginx转发请求到后端并返回的平均耗时是2ms那么瞬时在途请求大约是100000×0.002200个。这部分不大大头在keepalive长连接上。如果客户端开启HTTP长连接且并发连接数高达几万每个worker都要分摊一部分所以max-worker-connections设成65535、甚至更高都合理。注意Nginx本身还受文件描述符限制系统层要同步调大fs.file-max和容器进程的ulimit。对应ConfigMap片段data: worker-processes: 8 max-worker-connections: 65535改完以后执行kubectl rollout restart deployment/nginx-ingress-controller或者等待自动reload。验证方法看Nginx状态页curl -s http://127.0.0.1:10246/nginx_status观察Active connections和Reading/Writing等数值看是否随压测压力同步变化。3.2 全链路keepalive不只调一个客户端超时很多人都知道要在Ingress上开启keep-alive但容易漏掉上游连接池这一环。Ingress Nginx转发到后端服务时如果每次请求都新建TCP连接10万QPS下会产生海量的TCP握手和TIME_WAIT压力全部转嫁到内核协议栈。所以全链路keepalive至少包含三段第一段是客户端到Ingress Nginx的keepalive。ConfigMap里对应两个参数keep-alive-requests表示单个客户端长连接最多能复用的请求数keep-alive-timeout表示空闲连接保留时长。默认值通常够用但在高并发下建议把keep-alive-requests从默认提升到10000keep-alive-timeout保持60到75秒即可。第二段是Ingress Nginx到后端的upstream keepalive。这个是关键对应三个参数upstream-keepalive-connections每个upstream保留的空闲长连接数默认值偏小我调到了2048upstream-keepalive-requests单个上游连接最多复用的请求数默认1000我调到10000upstream-keepalive-timeout上游空闲连接保留时间默认30秒左右可以调到60秒顺带说一句upstream-keepalive-connections并不是越大越好因为保留的长连接也是资源。它需要同时覆盖后端Pod数量和后端支持的最大连接数。如果后端服务本身连接数上限很低你把Ingress侧调得很大也没有意义反而增加Nginx和后端的负担。第三段是HTTP/2多路复用。如果客户端支持HTTP/2一个TCP连接上可以同时跑多个请求这会显著减少客户端连接数量。ConfigMap里enable-http2默认是true保持即可。3.3 超时、缓冲与请求体隐性开销处理的取舍超时和缓冲参数是调优时最容易“抄错”的一类因为每个人的业务场景不同。我在这次10万QPS压测里用到的几个核心参数和理由放在下面这张表里参数推荐值原因proxy-connect-timeout10后端建连超时太长会在后端异常时卡住workerproxy-read-timeout60等待后端响应的超时按业务最慢接口的P99设计proxy-send-timeout60后端读取请求体的超时client-header-buffer-size16k默认通常较小请求头复杂时容易触发多余缓冲分配large-client-header-buffers4 32k与上面配合减少大请求头场景下的临时缓冲频繁分配client-body-buffer-size1m请求体缓冲设太大容易内存浪费设太小会触发临时文件IO这里要强调的是全部照抄我的值并不一定适合你的业务。比如proxy-read-timeout我做压测的接口都是几十毫秒返回的60秒只是兜底如果你的业务里有慢接口这个值需要单独调大否则会出现偶发504。proxy-buffering也值得单独说说。默认开启时Nginx会把后端响应缓冲到内存再发给客户端这对性能有正向帮助因为Nginx可以快速释放后端连接。但如果你跑的是超大响应体或流式接口缓冲反而会占用内存和延迟可以按Ingress annotation单独关闭不建议全局关。3.4 日志与压缩高频IO与CPU的第一降耗点在10万QPS量级日志和压缩的开销会被放大得很夸张。默认的log-format-upstream会把大量字段拼成一行每个请求都写一次磁盘IO和CPU字符串处理都是额外成本。而gzip每压缩一个响应都会吃掉CPU周期。这次压测里我做的第一个改动是关闭access logdata: disable-access-log: true直接在ConfigMap里禁用压测日志完全丢掉QPS提升非常明显。不过生产环境不建议长期全关因为排障需要访问日志。折中的方案是用更精简的log-format-upstream替代默认格式只记录时间、状态码、请求路径、上游耗时并且让日志走标准输出到容器日志收集器不直接写本地磁盘。压缩方面gzip默认开启且级别偏高我压测时直接把gzip-level降到了1并把gzip-types限制在text/css、application/javascript等少数文本类型图片、视频等已经压缩过的内容不做重复压缩。如果环境支持可以开启enable-brotli: trueBrotli在相同压缩比下CPU开销在某些场景比gzip更可控但也要实测对比不能无脑开。还有一个小细节动态压缩对高频接口性价比很低因为大部分响应体的内容可能都是可预测模板。更好的方案是在业务侧做静态压缩Ingress直接透传CPU开销几乎为零。4. TLS成本控制目标10万QPS必须跨过的第二道坎4.1 一次握手实际要消耗多少CPUTLS是性能压测中最容易低估的杀手。一次完整的TLS握手尤其是ECDHE密钥交换需要执行椭圆曲线点乘等非对称计算。虽然现在CPU都支持AES-NI等硬件加速但握手本身的计算开销依然远高于普通HTTP请求转发。我做过一个简单对照实验同一个8核节点、同样的配置纯HTTP转发能跑到9万QPS左右一旦全部走HTTPS新连接握手QPS会掉到不到一半。原因很直观每个新连接进来都要做一次握手握手消耗的CPU可能是普通转发请求的5到10倍。如果10万QPS全是新TLS连接CPU直接被打爆Nginx配置怎么调都救不回来。所以TLS调优的核心思路不是让握手更快而是尽量少握手、复用会话。4.2 会话缓存与会话复用的正确开启姿势Nginx侧需要开启TLS会话缓存让一定时间内复用相同会话的客户端免去完整握手。ConfigMap中相关的参数是ssl-session-cache: true开启会话缓存ssl-session-cache-size: 50m缓存容量默认10m压测中我调到了50mssl-session-timeout: 30m缓存有效期默认较短针对高复用连接可以放宽到30分钟ssl-buffer-size: 16k握手时发送的缓冲大小开启后客户端如果支持TLS Session ID或Session TicketTLS握手的第二次请求就能走简化握手CPU开销大幅下降。但问题在于客户端不一定每次都复用会话很多压测工具默认也不会复用TLS会话。比如用wrk压HTTPS时如果脚本里不带session复用逻辑测出来的就是最坏情况性能数据会很难看。这并不意味着生产环境一样差你要看真实客户端的TLS复用率。用h2load压HTTP/2时它会主动复用TLS会话测出来的数据更接近真实浏览器场景。生产环境建议通过监控TLS握手速率来确认会话复用率如果握手速率过高大概率是客户端每次请求都新建连接这时候要考虑调大保活时间和会话缓存或者推动客户端接入长连接。4.3 密码套件与算法选择性能和安全的平衡密码套件的选择也会影响CPU占用。旧版本的Nginx配置可能还带着ECDHE-RSA-AES256-GCM-SHA384这类强套件但它不是性价比最高的。在兼顾安全和性能的前提下我这次使用的是以下推荐套件配置ssl-protocols TLSv1.2 TLSv1.3; ssl-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; ssl-prefer-server-ciphers on;优先顺序是AES128-GCM比AES256快一些安全性在绝大多数业务场景足够。TLS 1.3默认使用更强且更快的握手一定要放到支持的协议范围里。全套配置在ConfigMap里可以直接通过ssl-ciphers和ssl-protocols设置。这里还要注意证书本身的性能使用ECDSA证书比RSA证书握手更快因为ECDSA签名体积小、验证开销低但证书签发链支持情况需要评估。如果业务方已经用了某个公开CA的RSA证书贸然更换成本高可以在需要极致性能的边缘场景单独给新证书或者把证书转到前置LB处理。4.4 该不该把TLS卸载到前面的负载均衡器聊到这里很多人会问既然TLS这么吃CPU那干脆把证书放在Ingress前面的负载均衡器上让LB做TLS卸载Ingress只处理明文HTTP是不是更好这个方案确实能显著降低Ingress Nginx的CPU负担。如果你的LB支持TLS终止并且已经把证书管理、自动续期做得很成熟那卸载到LB往往比在Nginx里做更省事。尤其是全站HTTP/2和高并发长连接场景LB承担的握手量可能成为新的瓶颈但那属于LB的扩展能力问题不管Ingress的事了。但卸载TLS也有代价一是LB到Ingress之间的链路如果是集群内部明文HTTP需要确保网络隔离可信二是Ingress侧拿不到加密连接信息有些基于TLS特征的限流或安全策略会失效三是排查问题时链路跳数变多。我的建议是如果Ingress就是最终网关且节点CPU可控保留TLS在Ingress做并调好会话复用如果后端Ingress已经需要承受大量TLS握手且CPU打满卸载到LB是合理选择。这两种方案没有绝对的对错核心是明确你的瓶颈到底在哪一层。5. 从5万到10万一轮完整压测与排障记录5.1 压测工具选型与压测机本身的问题要做10万QPS的压测工具选错了会闹笑话。我这次用的组合是wrk、h2load和vegeta各有分工wrk主要压HTTP/1.1场景支持多线程和连接数控制简单高效适合打纯HTTP和HTTPSHTTPS记得确认会话复用行为h2load压HTTP/2多路复用的首选能一次建立大量HTTP/2连接模拟真实浏览器和移动端长连接场景vegeta适合恒定压力长时间压测结果统计做得比较完善我用来做10分钟稳定性验证压测机本身也容易成为瓶颈。很多人在压测机上没调内核参数压到5万QPS时压测机自己的文件描述符或者端口先不够了。比如wrk默认每个线程创建大量连接Linux默认的ulimit -n只有1024不调大根本压不动。压测机至少需要把fs.file-max、net.ipv4.ip_local_port_range同步调大再用多台压测机对目标打流量避免单台压测机自己先被拖垮。如果你只有一台8核压测机还在同一台机器上跑压测工具和监控脚本那压测数据的可信度就打折扣了。我给的建议是压测机至少2台每台4核以上压测工具和mpstat、ss这些监控命令不要和目标Ingress节点混跑。5.2 第一轮压测CPU没用满但QPS上不去的怪事进入正题。第一次调整完软中断、内核参数和前面列出的ConfigMap配置后我满怀期待地开跑结果QPS卡在7.2万左右上不去了。top显示Nginx worker CPU总共才50%8个核里有两个偏高、其他不活跃。CPU没顶满QPS却先见顶这种“资源没用满但吞吐卡死”的情况最容易让人困惑。我当时的排查链路是这样的这条链路也值得记录第一步先用mpstat -P ALL 1看CPU分布。这时候发现硬中断和软中断已经均匀了问题不在中断了。但同时注意到有两个CPU的%sys特别高说明内核态在大量干活。第二步用ss -s和ss -nt state time-wait看连接状态。结果显示Time-Wait连接数量非常多每秒新建连接数量接近20万有些异常。这背后是wrk压测时没有开启keepalive复用导致每个请求都是新建TCP连接。这既是压测方法问题也是一个直观的信号真实业务如果也这样高频新建连接内核协议栈压力极大。第三步用dmesg看内核日志发现大量nf_conntrack表满的报错。K8s节点上conntrack是一个常见的隐藏限制默认表大小通常只有几十万条高连接场景下很容易满了丢包。这一步的真实命中比我想象中来得快。排障动作分两步走压测端wrk加-H Connection: keep-alive并限制并发连接数在一个合理区间降低新建连接速率节点上调大conntrack表和桶大小sysctl -w net.netfilter.nf_conntrack_max2097152 sysctl -w net.netfilter.nf_conntrack_buckets524288顺带说一下K8s很多组件都依赖conntrack调大前要确认安全别把节点内存打爆。这次调整后QPS直接从7.2万跳到9.1万问题的根源根本不是Nginx配置而是压测方法和连接跟踪能力。5.3 第二轮压测QPS上去了P99却开始抖动到了9.1万QPS离目标只剩一小步但P99延迟开始变得不稳定。10分钟内P99在7ms和35ms之间来回跳明显有周期性抖动。我一度怀疑是后端服务扛不住但通过后端监控看上游的P99一直在3ms以内问题还是出在Ingress这一层。这次我重点排查了两个点。第一是容器CPU throttle。前面提到过CPU limits8时如果瞬时突发流量超过8核cgroup会强制节流表现为P99抖动。用cat /sys/fs/cgroup/cpu.stat一看确实有nr_throttled增长。这说明8核在突发流量下已经有点紧张了光是调大limits不现实因为节点总共就那些核更好的思路是降低瞬时突发度比如在压测时控制并发连接增长速率让压力不是一次性涌进来。实际生产中这对应的是真实流量模型中突发尖峰的处理我会在模块末尾再说。第二是Nginx worker之间锁竞争。高并发下如果多个worker频繁争用共享锁也会出现CPU没打满但P99抖动的现象。用perf top看了内核热点确实看到了spinlock相关的符号占比不低。这个问题的根源之一是worker进程太多或连接分配不均尝试把worker-processes从8降到6后P99抖动有所缓解但总QPS下降了一点说明8个worker还是必要的。后来我没有强行压worker数而是通过开启HTTP/2多路复用来降低总连接数让每个worker的单位连接处理效率更高。最终P99回到了个位数毫秒。5.4 最终结果与调优前后对照最终的配置跑通后我用三台压测机同时打这台Ingress连续10分钟压力测试数据如下指标默认配置调优前调优后最终值单机QPS48,000102,000P99延迟21ms8msCPU整体占用72%68%软中断单核最大占用95%18%每秒新建TCP连接数约11万约2.1万后端P99延迟3ms3ms这份数据只是我这次压测环境下的结果不代表所有节点都能复现一模一样的数字。但它至少说明了一个问题10万QPS不是靠某一个单一配置项魔法般达成的而是底层中断分散、内核参数、Nginx keepalive链路、TLS会话复用、压测方法层层叠加的结果。每一个单点的提升都有限合在一起才冲过10万线。6. 结束语关于配置秘籍我想再提醒几件事这套配置跑通之后我在团队内部把ConfigMap固化成了标准模板后来其他业务接入时也直接复用。但有几句话我必须在最后单独拎出来说。第一这套调优默认你的后端响应足够快。如果后端接口P99本身就是200ms那Ingress再强的配置也只是把排队问题隐藏在后端QPS天花板会由上游决定你在Ingress侧看到的不再是性能瓶颈而是超时和排队积压。第二线上环境建议在10万QPS目标上留足余量。我压测达到10万QPS时CPU整体已经接近68%如果再叠加突发流量、日志收集、故障恢复等真实因素单机长期扛满10万是很危险的。实际容量规划建议按6到7万单机预留超出部分用副本横向扩容。第三每次改ConfigMap之后不要只看QPS有没有涨要看错误率和P99有没有恶化。Nginx的server-snippet、http-snippet这类自定义配置很容易改坏全局线上尽量少用。最后分享一个实用小技巧压测结束后把ConfigMap里每一项改动的记录和当时的QPS、P99对应起来形成一张自己的调参对照表。不同业务对延迟和吞吐的敏感度不一样我的“秘籍”只能作为起点真正属于你的配置需要用自己的流量模型反复压出来。