To be able to lighten Apache's load people frequently suggest using lighttpd for everyone up static content.

e.g. http://world wide web.linux.com/feature/51673

Within this setup Apache passes demands for static content to lighttpd via mod_proxy, while serving dynamic demands itself.

My real question is: so how exactly does this lessen the strain on the server? Since you've still got an apache process created for each request that is available in, so how exactly does this positively impact the burden? From what I can tell how big the Apache process proxying its request through lighttpd is as huge as it might be whether it were serving the file itself.

Running Lighttpd behind Apache for everyone static files certainly appears braindead in my experience. Apache still needs to unpack the HTTP packets and parse the request through its parse tree, send proxy demands, after which Lighttpd needs to re-unpack, hit the filesystem and send the files back through Apache. I have never heard about anybody utilizing a setup such as this in production.

What you should see, is people utilizing a lightweight webserver like Nginx like a frontend server for everyone static files and proxy dynamic Web addresses to Apache. Or, you are able to run Varnish or Squid like a caching reverse proxy frontend, to ensure that all of your high-traffic static files (i.e. images, CSS etc. and any dynamic pages you are prepared to send cache-friendly headers for) are offered from memory.

Apache may also be enhanced for everyone static files -- so frequently after i hear people complain about Apache, they don't understand how to configure it. They have only ever used the prefork MPM (versus. threaded or worker) and also have a variety of modules enabled (usually they are running from the Linux distribution's kitchen-sink Apache package that develops everything as modules and defaults to enabling 10-20 modules or even more). Tune Apache by turning off needless modules/stupid features like support for .htaccess (making Apache scan the filesystem on every request!) first. (You may also run two cases of Apache, having a "light" Apache as frontend that proxies to some "heavy" Apache for dynamic demands ... maybe your frontend is threaded however your after sales is prefork because you need to run thread-unsafe exterior modules like mod_php.)

Re:

Since you've still got an apache process created for each request which comes in, so how exactly does this positively impact the burden? From what I can tell the dimensions from the Apache process proxying its request through lighttpd is really as large as it might be whether it were serving the file itself.

If you are breeding processes on every request, then which means you are while using prefork MPM. Bear in mind that after the OS reviews memory usage for all these processes, not every that memory is wired, lots of individuals processes are idle. So when you are speaking about speed, you are concerned more with request parsing and internal code branches for any given request (just how much processing may be the server doing?) compared to memory usage reported through the OS.

For instance, should you enable something similar to mod_php, then all of individuals worker processes will instantly increase by about 20-40M (based on what's enabled inside your PHP interpreter), but that does not mean Apache is applying that memory on static demands. Obviously if you are optimizing your server for optimum concurrency on small static files, then enabling mod_php would be very bad, you are not likely to have the ability to fit as many prefork processes into RAM.

I most likely could develop a "nightmare configuration" for Apache that would allow it to be really reduced serving static files than proxying individuals demands to some after sales Lighttpd, however it would involve enabling costly features like .htaccess in Apache which are disabled in Lighttpd, therefore it wouldn't be fair.