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