如何优化 Nginx 性能?

看到那张站在虚拟键盘前操作 Nginx 负载均衡的图，我忽然想起之前处理过的一个真实案例。一个日活百万的电商 App，在某个大促前夕，技术团队发现他们的 Nginx 服务器在高峰期响应时间会飙升到秒级，页面加载慢得让人抓狂。他们当时的第一反应是加机器、堆配置，但成本飙升后效果却一般。后来经过一系列 「手术刀式」 的精准调优，硬是把平均响应时间压到了 200 毫秒以内，还没增加硬件预算。这让我深刻体会到，优化 Nginx 性能，很多时候不是 「大力出奇迹」，而是需要一些精巧的 「手艺活儿」。

别让连接管理拖了后腿

很多人一上来就琢磨 worker_processes 和 worker_connections，这当然没错。但有个细节常被忽略：keepalive_timeout 和 keepalive_requests。你知道吗？在某个高并发 API 服务里，他们发现后端 Tomcat 的连接数总是居高不下，一查才发现，Nginx 默认的 keepalive_timeout 设了 75 秒，而他们的 API 平均响应才 50 毫秒。这意味着大量连接在完成工作后，还白白占着资源 「发呆」 几十秒。把它调到 10 秒，同时把 keepalive_requests 从默认的 100 提高到 1000，让单个连接能处理更多请求，后端连接池压力瞬间降了 60% 以上。这个改动几乎零成本，但效果立竿见影。

缓存策略：不只是 「打开开关」 那么简单

说起缓存，十有八九的人会配置 proxy_cache。但你真的了解缓存的失效和更新策略吗？我见过一个惨痛的教训：一个资讯网站为了追求极致性能，把文章详情页缓存设了 1 小时。结果小编后台修改了文章，前端用户刷了一小时还是旧内容，差点引发运营事故。所以，动态内容的缓存策略必须和业务逻辑结合。比如，可以用 proxy_cache_key 把用户 ID、文章版本号都包含进去，或者利用 proxy_cache_bypass 和 proxy_no_cache 指令，通过 Cookie 或特定请求头来绕过缓存。更高级的玩法是 「边缘缓存」，配合 Cache-Control 头，让 CDN 和浏览器也参与到缓存体系中，这比单纯依赖 Nginx 这一层要聪明得多。

哦对了，还有 Gzip 压缩。这几乎是标配了，但压缩级别 gzip_comp_level 你设的是几？默认是 1，有人为了追求更高压缩比，盲目调到 6 甚至 9。结果 CPU 使用率上去了，压缩效率的提升却微乎其微。对于文本内容，级别设在 3 到 5 之间通常是最佳平衡点。还有 gzip_min_length，小于这个长度的响应就别压缩了，不然压缩后的体积可能比原文件还大，纯属浪费 CPU。

日志与监控：性能优化的 「眼睛」

性能优化最怕什么？最怕 「盲人摸象」。没有准确的度量，所有调优都是凭感觉。Nginx 的 stub_status 模块能提供基本的活跃连接数、请求处理数，但这远远不够。我强烈建议把日志格式优化一下，在 log_format 里加上 $request_time 和 $upstream_response_time。这两个值一对比，你就能清晰看出时间到底花在了 Nginx 自身处理上，还是卡在了后端应用。如果 $request_time 很大但 $upstream_response_time 很小，那问题很可能出在客户端网络慢或者 Nginx 的发送缓冲区设置上，该去调 send_timeout 或者 sendfile 参数了。

说到底，Nginx 性能优化没有一套放之四海而皆准的 「银弹参数」。它更像是一个持续观察、提出假设、验证调整的过程。从连接管理、缓存策略到缓冲区和日志，每一个环节都有值得深挖的细节。关键是要结合自己业务的实际流量模式和数据，像侦探一样去分析和实验，才能让这台高性能的引擎，真正为你所用。