Depends heavily on how you have configured Apache. If you are using something like PHP and the forking model (most common MPM configuration), you can only handle as many requests as you have workers; additionally you are spinning up a full PHP interpreter when serving static assets. In my experience[1], putting Nginx in front of Apache to serve static assets and leaving Apache as a sort of application server is one of the lowest hanging fruit in scaling a LAMP application.

[1] Was Co-Founder/CTO of a medium-sized PHP PaaS company

> additionally you are spinning up a full PHP interpreter when serving static assets.

I think that if you do this you are one RewriteRule away from doing it right.

> In my experience[1], putting Nginx in front of Apache to serve static assets and leaving Apache as a sort of application server

I also think that using nginx only for static content is wasting perfectly good resources for nothing. Apache can serve static assets just as good as nginx does. No need for an other layer in your stack.

I'd agree, but I suspect that anybody who cares about PHP-performance has probably already moved to FPM.

This was how we did it at my last job, a state university.

Depends. I remember having an issue with an apache/mod_php app that was using way too much memory.

The app was doing polling every 10 seconds and apache had a 15 seconds keep alive. So each user of the app was maintaining an apache process alive.

Disabling the keep-alive was not acceptable, so I just threw nginx in front to do the keep-alive, memory usage was immediately reduced by ~75%.

If I knew apache better I might have been able to do it with just apache, but nginx is so simple to use...

wouldn't just changing the apache keep alive have been even easier than setting up a whole other web server and adding that to the mix?

If the nginx keep alive was set at 15 seconds, you'd have had a similar problem, no?

No. Because Nginx doesn't dedicate a thread or process to each open connection.

Doesn't that raise security concerns?

Yes, it requires a sandbox for things like PHP.

But it's limited to it. Most other web stacks come with their own sandbox. And Apache also puts PHP in a sandbox for unrelated issues.

At absolute bare minimum it allows for error mitigation for the underlying server application.

In other words, your site doesn't necessarily have to be down even if Apache is down (assuming you're for some reason bound to Apache).