Nginx性能需事件模型、内核参数与压缩模块协同调优：启用epoll、multi_accept及调高somaxconn/tcp_max_syn_backlog；gzip仅限文本、设合理等级与阈值；buffer和keepalive需匹配业务特性，启用sendfile与directio优化传输。
匹配事件模型与系统网络栈能力
Linux下必须启用epoll，这是Nginx事件循环高效的基础：
-
use epoll;写入
events{}块，禁用过时的select或poll - multi_accept on;让每个worker一次接收多个就绪连接，避免“惊群”后反复唤醒
- 配套调整内核
net.core.somaxconn（建议65535）和net.ipv4.tcp_max_syn_backlog（同步设为65535），否则即使Nginx想多接，内核队列已满，新连接直接被丢弃 - 确认应用层未被限制：通过
ulimit -n检查当前打开文件数，若低于worker_connections × worker_processes，需同步配置/etc/security/limits.conf
压缩策略需适配连接行为与缓冲机制
Gzip压缩不是开就完事，它直接影响每个连接的数据吞吐节奏和buffer占用：
-
仅对文本类响应启用压缩：设置
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;，避免压缩图片、视频等已压缩资源，徒增CPU开销 -
控制压缩级别与阈值：使用
gzip_comp_level 4;（平衡速度与压缩率），配合gzip_min_length 1024;，防止小响应（如空JSON、短提示）触发无意义压缩 -
压缩与TCP包策略联动：启用
tcp_nopush on;后，压缩后的整块响应更易凑满MSS，减少小包；但若业务含大量实时小消息（如WebSocket心跳、SSE流），应关闭tcp_nopush并确保tcp_nodelay on;生效
缓冲区与连接生命周期要统一规划
事件循环处理效率受限于内存带宽和上下文切换，而buffer大小和keepalive策略直接影响这两点：
-
客户端请求缓冲不宜过大：如
client_header_buffer_size 2k;和large_client_header_buffers 4 8k;可防恶意长header耗尽内存，也减少单次读取延迟 -
keepalive_timeout需匹配压缩场景：若开启Gzip且响应体变小，连接复用价值更高，可设为
keepalive_timeout 45s;；但若后端是动态服务且首字节延迟波动大，建议缩短至20–30s，避免空闲连接长期占用工况资源 -
禁用不必要buffer复制：启用
sendfile on;跳过用户态拷贝，再配合directio 4m;（大静态文件）可进一步绕过页缓存，降低内存压力
