Apache与Nginx性能调优实战

2024版核心架构差异：从Prefork到Event与Epoll的演进

很多刚入行的同学问我，为什么现在的互联网公司很少直接把Apache推到公网前沿了？要回答这个问题，我们得回到2016年我接手的一个传统企业官网项目。那时候服务器用的是Apache 2.2，配置的是经典的Prefork模式。当时服务器配置是单颗Intel E5-2620，内存16G，跑一个日均5万PV的PHP企业站，看起来绰绰有余。

但有一次，市场部搞活动，瞬间并发冲到了300多，服务器直接挂了。我登上去看，满屏都是httpd进程，每个进程占用了将近20MB内存。这就是Prefork模式的典型特征：它是多进程模型，一个连接对应一个进程。你可以把它想象成一个银行柜台，来一个客户（请求），就开一个窗口（进程）专门服务。客户不走，窗口就不关。如果突然来了300个客户，银行就得开300个窗口，每个窗口都要占地方（内存），银行大厅（服务器）瞬间就被挤爆了。

后来我们把Apache升级到了2.4.58（这是2023年10月发布的稳定版，也是目前生产环境的主流版本），并切换到了Event MPM。Event模式聪明在哪里？它引入了专门的监听线程。还是拿银行举例，现在不是每个客户独占一个柜员了，而是有一个大堂经理（监听线程）专门负责接待，把客户引导到等候区，真正的柜员只在客户需要办理业务（请求数据就绪）时才介入。这大大减少了空闲时的资源浪费。

但这依然是基于进程的模型。直到我后来主导引入Nginx 1.26.0（2024年4月刚发布的Stable版），我才真正理解了事件驱动架构的降维打击。Nginx基于Epoll（Linux环境下），它就像一个超级服务员，只需要一个人，就能同时盯着成千上万桌客人的状态。哪桌客人举杯了（数据可读），他就过去倒酒；哪桌客人叫买单了（连接关闭），他就过去处理。他不需要一直守在某一桌旁边。

这种异步非阻塞IO的能力，让Nginx在处理静态资源（图片、CSS、JS）时，单进程就能轻松扛住数万并发连接，而内存消耗可能只有几MB。

这里我贴一段当时为了验证两者差异，在测试环境写的简单压测对比配置和结果分析。我们当时用wrk对一个10KB的静态文件进行压测，并发1000，持续30秒。

Apache 2.4.58 (Event MPM) 关键配置:

<IfModule event.c>
    ServerLimit             16
    StartServers            3
    MinSpareThreads         75
    MaxSpareThreads         250 
    ThreadsPerChild         64
    MaxRequestWorkers       1024
    MaxConnectionsPerChild  10000
</IfModule>

*场景说明：当时我们限制了最大1024个并发工作线程。压测结果显示，虽然能抗住，但CPU的上下文切换开销非常大，因为线程数依然不少。*

Nginx 1.26.0 关键配置:

worker_processes auto; # 自动根据CPU核数设置
events {
    worker_connections 10240; # 单个worker进程的最大连接数
    use epoll; # 明确指定使用epoll模型
}

*场景说明：Nginx这边，我们只开了跟CPU核数一样的进程数（比如8核就8个进程），每个进程能处理1万多个连接。压测时，Nginx的CPU占用率极低，几乎全是内核在处理网络中断，内存增长微乎其微。*

这就是架构上的根本差异。Apache的演进（Prefork -> Worker -> Event）是在进程/线程模型内部做优化，而Nginx则是直接换了赛道，用事件驱动解决了C10K问题。如果你现在的业务是重动态的，且依赖.htaccess这种目录级配置，Apache 2.4.59（2024年4月的最新版）依然稳健；但如果是高并发的API网关或静态资源服务，Nginx 1.25.5（Mainline版）或1.26.0才是2024年的首选。

实战复盘：百万日活社区从Apache迁移至Nginx的压测数据

去年我负责了一个垂直社区的技术重构，这个社区有约120万日活用户，峰值QPS接近8000。原来的架构是经典的LAMP（Linux + Apache 2.4 + MySQL + PHP），跑在16核32G的云主机上。虽然用了Apache 2.4的Event模式，但在晚高峰（晚上8点到10点）经常会出现请求排队的情况，平均响应时间从常态的200ms飙升到1500ms以上，用户投诉刷不出帖子列表。

当时排查发现，瓶颈不在PHP-FPM，也不在数据库，而在Apache的连接处理上。虽然用了Event模式，但Apache在处理大量Keep-Alive连接时，依然会占用相当数量的线程在等待。你可以理解为，虽然大堂经理（监听线程）很高效，但后台还是有很多柜员（工作线程）在等着那些还没断掉的电话（Keep-Alive连接），导致新来的客户没人服务。

我们决定引入Nginx作为前端代理，后端依然对接PHP-FPM。迁移不是一蹴而就的，我在测试环境做了详细的压测对比。

我们模拟了晚高峰的场景：并发连接数5000，持续时间5分钟，请求混合了静态资源（70%）和动态接口（30%）。

压测环境配置对比：

| 指标 | Apache 2.4.58 (Event) | Nginx 1.26.0 (Proxy) |

| :--- | :--- | :--- |

| 静态QPS | 3,200 | 18,500 |

| 动态QPS | 2,100 | 6,800 |

| 平均延迟 | 450ms | 85ms |

| 内存占用 | 1.8GB (峰值) | 150MB (峰值) |

| CPU使用率 | 85% (波动大) | 35% (平稳) |

这个数据让我非常震惊。特别是静态资源，Nginx的性能是Apache的5倍以上。原因很简单，Nginx处理静态文件几乎不需要像Apache那样经过复杂的模块钩子（Hook）链，它直接通过内核的sendfile机制把文件发出去，效率极高。

在迁移过程中，我遇到了一个具体的坑。原来的系统大量使用了.htaccess来做伪静态和访问控制。Nginx是不支持.htaccess的，因为它追求的是集中式、解析后的配置，而不是每次请求都去读取目录下的配置文件（这也是Nginx快的原因之一）。

我不得不手动把.htaccess规则翻译成Nginx的location和rewrite规则。比如原来Apache里的一段规则：

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ index.php/$1 [L]
</IfModule>

在Nginx里，我必须写成这样，并且要配合try_files指令，否则会出现404或者循环重定向：

location / {
    try_files $uri $uri/ /index.php?$query_string;
}

location ~ \.php$ {
    fastcgi_pass   unix:/var/run/php/php8.2-fpm.sock;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include        fastcgi_params;
}

*场景说明：在迁移初期，我直接用了rewrite ^(.*)$ /index.php/$1 last;，结果导致Nginx CPU飙升，因为正则匹配太频繁。后来改用try_files，利用Nginx的内部重定向机制，性能提升了30%。*

上线后，效果立竿见影。晚高峰的平均响应时间稳定在100ms以内，服务器负载从原来的15（16核）降到了2。这次迁移让我深刻意识到，对于百万级日活的场景，前端接入层的架构选择直接决定了系统的生死。Apache依然是个好同志，但在高并发接入这个维度上，2024年的Nginx确实更胜一筹。

独家调优：Apache MPM Event与Nginx Worker连接数极限配置

很多教程会告诉你，把worker_connections调大，把MaxRequestWorkers调大，但很少有人告诉你为什么要这么调，以及调大了之后会有什么副作用。我结合自己运维过的一个高并发短连接API服务（峰值QPS 1.2万）的经验，聊聊这两个服务器的极限配置。

先说Apache 2.4.59（2024年4月发布的最新版）。在Event MPM下，核心参数是MaxRequestWorkers和ThreadsPerChild。

我曾经犯过一个错误，为了让服务器能抗更多并发，我把MaxRequestWorkers直接调到了2000。结果服务器内存直接爆掉，触发了OOM Killer。后来我算了一笔账：虽然Event模式比Prefork省内存，但每个线程依然需要占用一定的栈空间。如果ThreadsPerChild是64，MaxRequestWorkers是2000，那么就需要大约31个进程（2000/64）。每个进程除了线程，还有共享内存和模块占用的空间。

经过多次测试，我总结出一套适合16G内存服务器的配置：

<IfModule event.c>
    # 服务器启动时的进程数，保持默认或略高
    StartServers             4
    # 最小空闲线程数，防止突发请求时临时创建线程的开销
    MinSpareThreads         100
    # 最大空闲线程数
    MaxSpareThreads         400
    # 每个进程包含的线程数。不是越大越好，太大会增加锁竞争。
    ThreadsPerChild         64
    # 最重要的参数：最大并发请求数。
    # 计算公式：(内存总量 - 系统预留 - MySQL/Redis等占用) / 单个线程预估内存
    # 当时16G内存，留给Apache约8G，单个线程约10MB，所以8G/10MB ≈ 800
    MaxRequestWorkers       800
    # 防止内存泄漏，处理1万次请求后重启进程
    MaxConnectionsPerChild  10000
</IfModule>

*场景说明：为什么定800？因为当时我们观察到，每个httpd线程在满载时大约占用10-15MB内存（包含PHP模块等开销）。如果设置超过1000，一旦流量抖动，内存就会击穿。*

再来看Nginx 1.25.5 (Mainline版)。Nginx的配置看似简单，其实坑也不少。核心在于worker_processes和worker_connections。

user  www-data;
worker_processes auto; # 自动匹配CPU核数，我是8核就是8

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
    # 单个worker进程能处理的最大连接数
    worker_connections 10240;
    # 使用epoll，这是Linux下高性能的必备
    use epoll;
    # 允许一个worker进程同时接受多个新连接
    multi_accept on;
}

http {
    # 开启零拷贝，大幅提升静态文件发送效率
    sendfile on;
    # 优化tcp_nopush和tcp_nodelay
    tcp_nopush on;
    tcp_nodelay on;
    # 保持连接超时时间，高并发下建议适当缩短
    keepalive_timeout  30s;
}

这里有个关键点：worker_connections并不是越大越好。它受限于系统的文件描述符（File Descriptor）限制。Linux默认一个进程只能打开1024个文件描述符。如果你设了10240，Nginx会报错。

我当时就遇到过这个问题。排查过程是这样的：

发现Nginx日志里报worker_connections exceed open file resource limit。
检查ulimit -n，发现是1024。
修改/etc/security/limits.conf，增加：

`bash

* soft nofile 65535

* hard nofile 65535

修改Nginx的系统服务配置（Systemd），在[Service]段增加：

`ini

LimitNOFILE=65535

重启服务后，通过cat /proc/$(cat /var/run/nginx.pid)/limits | grep "Max open files"确认生效。

另外，worker_connections的计算方式是：worker_processes * worker_connections。比如8核CPU，10240连接，理论上能处理81920个并发连接。但这只是理论值，实际还要看带宽和CPU的处理能力。如果都是小包请求，8个进程处理8万连接完全没问题；但如果都是大文件上传，CPU和带宽早就先满了。

所以，调优不是无脑调大数字，而是要根据你的业务形态（短连接还是长连接、静态还是动态、包大小）以及系统资源（内存、文件描述符、CPU核数）来做权衡。对于2024年的云原生环境，我更倾向于把Nginx的worker_connections设在10240到20480之间，既充分利用了Epoll的优势，又不会给系统带来过大的FD压力。

4. 混合架构实战：为何我们最终选择了Nginx反代Apache的方案

去年我们接手了一个运行了7年的老牌电商系统，后端是基于 Apache 2.4.41 和 mod_php 构建的单体应用。在大促期间，我观察到一组令人头疼的数据：当并发连接数突破1500时，Apache的Prefork模式导致内存占用飙升到32GB，且平均响应时间从200ms劣化到1800ms。原因在于Apache的Prefork模式为每个请求分配一个独立的子进程，一个PHP进程常驻内存约40MB，一旦并发上来，物理内存迅速耗尽，进而引发SWAP交换，系统负载瞬间炸裂。

当时团队内部有两种声音：一是全部迁移到Nginx + PHP-FPM，二是保留Apache作为应用容器，前端加一层Nginx。我否决了全量迁移的方案，原因在于这个遗留系统的代码里充斥着大量的 .htaccess 重写规则和对 mod_rewrite 的强依赖，全量迁移的改造成本和风险在业务侧无法接受。解决方案是采用 Nginx (1.24) 作为前端代理 + Apache (2.4.58) 作为后端处理 的混合架构。

这种架构的核心逻辑在于：利用Nginx处理高并发的静态资源连接和SSL卸载，将动态请求通过代理转发给Apache处理。

我在一个测试环境中进行了压测对比。在纯Apache Prefork模式下，使用 ab -c 500 -n 10000 进行压测，QPS 仅为 320，且失败率极高。调整为 Nginx 反代 Apache 后，同样的并发量，Nginx 仅消耗了 50MB 内存就接住了所有连接，然后以较低的并发（例如20个连接）回源给Apache。原因在于Nginx的事件驱动模型能够高效地hold住这500个并发连接，而Apache只需要处理它擅长的少量动态请求，不再受困于进程上下文切换的开销。

在配置层面，我做了如下调整。首先，我将Apache监听端口从80改为监听在 127.0.0.1:8080，并关闭了 KeepAlive，因为保持连接的工作已经交给前面的Nginx了。

Apache 配置调整 (/etc/apache2/ports.conf):

# 禁止Apache直接对外，改为监听本地回环地址
Listen 127.0.0.1:8080

# 关闭Apache的KeepAlive，减少内存占用
# 因为连接管理已经由前端的Nginx负责
KeepAlive Off

Nginx 反向代理配置 (/etc/nginx/sites-available/ecommerce):

upstream apache_backend {
    # 定义后端Apache服务器组
    server 127.0.0.1:8080 fail_timeout=0;
}

server {
    listen 80;
    server_name example.com;
    root /var/www/html;

    # 静态资源直接由Nginx处理，不经过Apache
    location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
        expires 365d;
        add_header Cache-Control "public, immutable";
        # 直接返回文件，性能极佳
    }

    location / {
        # 动态请求代理给Apache
        proxy_pass http://apache_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        
        # 关键优化：设置连接超时时间
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }
}

实际部署后，效果立竿见影。有一次线上接口突然变慢，我排查下来发现是后端有一个PHP报表生成脚本执行了超过30秒。在纯Apache架构下，这会导致一个Apache子进程被长时间占用，进而引发阻塞。而在混合架构下，Nginx可以异步地等待后端响应，前端的用户连接并未断开，且Nginx本身不会因此阻塞其他请求。最终，我们将该脚本的超时时间通过 proxy_read_timeout 调整为300秒，完美解决了长耗时任务导致的502错误。

这种方案的取舍在于增加了架构的复杂度，多了一层网络转发。但在我们的场景下，它既保留了Apache对老旧应用生态（如 .htaccess）的兼容性，又获得了Nginx在并发处理上的性能优势。根据2024年4月发布的最新版本 Apache 2.4.59 的更新日志，虽然它在Event MPM上做了优化，但在面对突发流量时，Nginx的反代缓冲机制依然是更稳定的一道防线。

5. 云原生趋势：HTTP/3与QUIC在Nginx 1.26与Apache 2.4的最新支持

今年4月，Nginx发布了 1.26.0 Stable版，而Apache也更新到了 2.4.59。我在研究这两个版本时，重点测试了它们对 HTTP/3 和 QUIC 协议的支持情况。原因很简单，我们的移动端用户反馈在弱网环境下（如地铁、电梯）接口超时率高达5%，而TCP层面的队头阻塞是主要元凶。解决方案是尝试升级到基于UDP的QUIC协议。

在Nginx方面，从 1.25.x Mainline版开始，HTTP/3的支持已经相对成熟。在 1.26.0 中，虽然默认编译仍未开启QUIC，但官方对其支持已经进入了Stable通道。我在一台测试机（Ubuntu 22.04）上，使用Nginx 1.26.0重新编译了包含BoringSSL的版本。

Nginx 1.26.0 开启 HTTP/3 的配置示例：

http {
    # 开启QUIC和HTTP/3的日志
    log_format quic '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent" "$quic" "$http3"';

    access_log /var/log/nginx/access.log quic;

    server {
        listen 443 ssl;
        listen 443 quic reuseport; # 关键：同时监听UDP 443端口
        server_name example.com;

        ssl_certificate /etc/nginx/ssl/fullchain.pem;
        ssl_certificate_key /etc/nginx/ssl/privkey.pem;

        # 启用TLS 1.3，QUIC必须依赖TLS 1.3
        ssl_protocols TLSv1.3;

        # 告知浏览器支持HTTP/3的Alt-Svc头
        add_header Alt-Svc 'h3=":443"; ma=86400';

        location / {
            root /usr/share/nginx/html;
            # 尝试使用HTTP/3，如果不支持则回退
            quic_retry on;
        }
    }
}

配置完成后，我使用 curl --http3 https://example.com 进行验证。实测数据显示，在模拟丢包率5%的网络环境下，HTTP/3的页面加载完成时间比HTTP/2快了约35%（从平均1.2s降低到0.8s）。原因在于QUIC协议在弱网环境下不需要像TCP那样经历慢启动和重传的严格排队，它能更快地恢复连接。

反观Apache，情况则有些不同。在 Apache 2.4.59 中，官方并没有原生集成QUIC支持。我在查阅Apache官方Jira和邮件列表后发现，目前想要在Apache上跑HTTP/3，必须依赖第三方模块，如 mod_quic。我尝试在Apache 2.4.58上编译这个模块，过程极其痛苦，且稳定性存疑。原因在于Apache的架构基于传统的TCP套接字模型，要支持UDP层的QUIC，需要对核心网络IO部分进行大规模重构，这在短期内难以通过模块化的方式完美解决。

我在一次预发布环境的测试中发现了一个具体问题：当Nginx开启QUIC后，如果防火墙仅开放了TCP 443而忽略了UDP 443，连接会直接降级为TCP。排查过程花费了我大约两个小时，因为我一开始以为是证书问题。解决方案是检查安全组规则，确保UDP 443端口对外开放。

从云原生和K8s集成的趋势来看，Nginx Ingress Controller已经率先在最新版本中支持了HTTP/3的Annotation配置，而Apache在这一领域的步伐明显慢了一拍。根据2024-2026年的技术趋势分析，微服务架构下的gRPC流量和实时WebSockets通信将更加依赖这种低延迟的传输层。Nginx Unit虽然也在发展，但作为纯粹的Web服务器，Nginx 1.26.0在解决现代网络传输瓶颈（如队头阻塞）上，提供了比Apache 2.4更具前瞻性的解决方案。

对于开发者而言，如果你现在的架构还在使用Apache 2.4并且考虑升级到HTTP/3，我的建议是：不要试图在Apache上强行魔改，直接在前面加一层Nginx 1.26作为入口网关是成本最低、收益最高的路径。这不仅符合当下的技术趋势，也避免了在底层协议支持上耗费过多的精力。

站长实战手记

去年双十一前，我接了个电商客户的小项目，他们用的是Apache Prefork跑一个日活三十多万的促销页面。压测到每秒800请求的时候，服务器负载直接飙到15，响应时间从200毫秒掉到3秒，页面直接卡死。

我第一反应是调MaxRequestWorkers，翻到512还是崩。后来用strace跟进程，发现Prefork下每个请求都占一个进程，内存吃紧到连新连接都accept不了。我试着换成Event MPM，把AsyncRequestWorkerFactor调到2，情况好了一点，但到了1200并发还是顶不住。

最后我干脆在前面加了层Nginx做反代，静态图片、CSS、JS全让Nginx扛，只把动态PHP请求转给后面两台Apache。调Nginx的时候我把worker_connections设到4096，worker_processes绑定物理核，后端Apache的KeepAliveTimeout压到2秒。改完再压，单机轻轻松松过3000并发，负载稳在2以下，内存还省了快一半。

说实话，我现在的看法很直接：

* 小博客、内部系统，Apache Event MPM够用，别折腾

* 高并发、静态资源多的场景，Nginx是首选，别硬扛

* 别一上来就全换Nginx，有些老PHP项目依赖.htaccess，迁移成本比你想的高

我当年就吃过这个亏，为了“技术先进”把一套老系统硬迁到Nginx，结果重写规则花了三天，上线还出了一堆404。

如果你现在正纠结选哪个，先拿压测工具打一波真实流量，数据比任何架构争论都有用。别光看文档，动手跑一跑，你才知道自己的业务到底吃哪套。