在 Apache后面运行 Lighttpd来提供静态文件对我来说确实是个脑残。Apache 仍然需要解包 HTTP 数据包并通过其解析树解析请求,发送代理请求,然后 Lighttpd 必须重新解包,点击文件系统并通过 Apache 将文件发送回。我从未听说有人在生产中使用这样的设置。
您将看到,人们使用像Nginx这样的轻量级网络服务器作为前端服务器来为 Apache 提供静态文件和代理动态 URL。或者,您可以运行Varnish或Squid作为缓存反向代理前端,以便提供所有高流量静态文件(即图像、CSS 等以及您愿意为其发送缓存友好标头的任何动态页面)的记忆。
Apache 也可以优化为提供静态文件——所以当我经常听到人们抱怨 Apache 时,他们真的不知道如何配置它。他们只使用过 prefork MPM(与线程或工作线程相比)并启用了各种模块(通常它们从 Linux 发行版的厨房水槽 Apache 包运行,该包将所有内容构建为模块并默认启用 10-20模块或更多)。首先通过关闭不需要的模块/愚蠢的功能来调整 Apache,例如对 .htaccess 的支持(这使得 Apache 在每次请求时都会扫描文件系统!)。(您还可以运行 Apache 的两个实例,将“轻量级”Apache 作为前端代理到“重度”Apache 以进行动态请求......
关于:
由于您仍然为每个传入的请求生成一个 apache 进程,这对负载有何积极影响?从我可以看到,通过 lighttpd 代理其请求的 Apache 进程的大小与它为文件本身提供服务时一样大。
如果您在每个请求上都生成进程,那么这意味着您正在使用 prefork MPM。请记住,当操作系统报告每个进程的内存使用情况时,并非所有内存都已连接,其中许多进程处于空闲状态。当您谈论速度时,您更关心给定请求的请求解析和内部代码分支(服务器正在执行多少处理?)而不是操作系统报告的内存使用情况。
例如,如果您启用类似 mod_php 的功能,那么每个工作进程都会立即增加大约 20-40M(取决于您的 PHP 解释器中启用的内容),但这并不意味着 Apache 正在使用该内存静态请求。当然,如果您正在优化您的服务器以在小型静态文件上实现最大并发性,那么启用 mod_php 仍然会非常糟糕,您将无法将几乎尽可能多的 prefork 进程放入 RAM。
我可能会为 Apache 想出一个“噩梦配置”,它实际上会比将这些请求代理到后端 Lighttpd 更慢地提供静态文件,但它会涉及在 Apache 中启用昂贵的功能,例如在 Lighttpd 中禁用的 .htaccess,所以这真的不公平。