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