Apache性能优化核心是MPM模式选择与配置,优先使用Event MPM(2.4+唯一支持),需确认httpd -V输出为“Server MPM: event”;Prefork仅适用于非线程安全模块或极低负载场景;配置参数需逻辑匹配,如MaxRequestWorkers≤ServerLimit×ThreadsPerChild;同时禁用冗余模块、启用PHP-FPM及静态资源优化。

Apache 的性能优化,核心落在 MPM(Multi-Processing Module)模式的选择与配置上。它不是“选一个就行”,而是要匹配你的硬件、应用类型和运行环境——选错 MPM,再调参数也难救。
✅ 优先选 Event MPM:2.4+ 版本的唯一现代选择
Apache 2.4 已彻底移除 Worker MPM 支持,mpm_worker 加载会直接报错 Invalid MPM, 'worker' not supported。Event 不是“可选项”,而是当前架构下唯一推荐、线程安全、事件驱动的高并发方案。
- 它用单个监听线程 + 多个工作线程协作,靠 epoll(Linux)高效管理大量空闲连接;
- 同样硬件下,内存占用比 prefork 低 80% 以上,实测并发能力可提升数十倍;
- 特别适合 HTTP/2、长轮询、API 网关、静态资源分发等场景。
确认是否生效:
httpd -V | grep -i mpm
输出必须为 Server MPM: event —— 其他结果说明没真正启用。
⚠️ Prefork 只在特定场景下保留
Prefork(一请求一进程)仅适用于以下情况:
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
- 运行非线程安全的 PHP 扩展(如旧版 NTS PHP + mod_php);
- 应用本身不稳定、易崩溃,需要进程级隔离;
- 服务器负载极低(<100 并发),且管理员不熟悉线程模型。
一旦混用 PHP-FPM 或加载了任何非线程安全模块(如某些老版本 mod_python、mod_perl),Apache 会静默回退到 prefork 模式,即使配置写了 event —— 此时 ps aux | grep httpd 会看到一堆独立进程,而非少量多线程进程。
? 配置不是填数字,而是建立参数逻辑链
Event 的关键参数相互制约,不能孤立设置:
-
ThreadsPerChild:每子进程线程数,建议 25–100(4核起步设 25,16核可设 64); -
ServerLimit:最大子进程数,决定扩展上限; -
MaxRequestWorkers:全局最大并发线程数,必须满足MaxRequestWorkers ≤ ServerLimit × ThreadsPerChild; -
StartServers:启动时创建的子进程数,通常设为 CPU 物理核心数; -
MinSpareThreads / MaxSpareThreads:控制空闲线程池弹性,差值建议 ≥ThreadsPerChild; -
KeepAliveTimeout:务必设为 2–5 秒,过长会导致线程被空闲连接长期占用。
例如 8 核服务器常用组合:
StartServers 8 ThreadsPerChild 50 ServerLimit 16 MaxRequestWorkers 800 MinSpareThreads 150 MaxSpareThreads 300 KeepAliveTimeout 3
? 必须同步清理干扰项
MPM 再好,也会被这些拖垮:
- 关闭所有非必要模块:
a2dismod status info autoindex(Debian/Ubuntu)或注释LoadModule行(RHEL/CentOS); - PHP 务必走 PHP-FPM,禁用
mod_php; - 静态资源启用
mod_deflate(压缩)和mod_expires(缓存),让大量请求不进 Apache 核心处理链; - 提升系统级限制:
fs.file-max、nofile限制、TCPtw_reuse等需同步调优。
不复杂但容易忽略。


















