Using NginX and Apache alongside for both static and dynamic files

Question

Background:

I've searched a lot and found these useful threads about using of Apache or NginX for static or dynamic files. But they are old (mostly about 1 or 2 years ago) and I think both webservers, specifically Nginx has had important changes in performance and usage. So I think take another look on these issue cannot be that bad.

• Nginx (for static files) and Apache (for dynamic content)?
• nginx better than apache for dynamic content? [closed]
• Apache or NGINX for PHP?
• Nginx as reverse proxy to Apache with only dynamic content?

My question:

I have a PHP web application with lots of dynamic files and lots of static contents (videos, images etc.) and it's currently running on a CentOS 6 server and Apache 2.2 since 2 months ago.

In past few days, number of our site visitors have gained so fast and I just thought if this number continues to increase with current ratio, we need to change many things (web server, application, etc.) to prevent failures. Because of hardware limitations that we are facing, I thought that it's best for us to start with web server.

1. Should I start with something else? Should I try to increase performance of my PHP application and forget about web server for now? (even if gonna take a long time!)
2. Because of huge usage of .htaccess files (for redirection, rewrites, etc.), I think it's gonna be painful to migrate to NginX as default web server or maybe only for dynamic files. Does this mean that I can't even use Nginx as reverse proxy?
3. I'm not sure latest stable version of NginX and PHP-FPM have a better performance over my current Apache and my limitations (too many things) won't let me to give it a try. Which one is doing better currently?
4. What will I lose by migrating to Nginx?
5. To make it short, what should I do?

Answer 1

To answer your questions, you need to provide more information. You have to figure out where your bottleneck is, and why! Is it servers resources, like CPU or Memory or disk I/O. Where do you think things will break if the visitor count keeps increasing?

When you answer the where, you need to figure out the why. Is your system simply undersized for the task it's been given? Is your application efficient? Is communication between clients and server efficient, for example with proper Cache-Control headers, compressed transfers, few HTTP requests, etc.?

A quick solution would be to kick all static assets off your servers. Host them in a CDN, for example S3 with CloudFront, and the requests will never even hit your server.

We ran into a similar situation a year ago, when our trending graphs showed imminent problems. Our application turned out to be too CPU-heavy, and we were passing all requests for static assets through the application for various ACL checks even for public files, which lead to a high load. My research showed that while a threaded webserver like Nginx or Apache-worker would help limit memory use, it wouldn't help reduce CPU usage much for our PHP processes. We needed to simply reduce the number of dynamic requests.

Our solution was to install Varnish in front of Apache to cache static assets and cache dynamic content. A single Varnish instance with 1 Gig of RAM can handle thousands of requests for static files per second with very low CPU load. Varnish is by default very conservative in what it caches, since it doesn't know what's safe to cache, so don't expect an immediate improvement. It took some tweaking to our application to get good results, and you'll learn a lot about HTTP and your apps, but now we're serving about 80% of all requests from Varnish, for about 0.2% CPU usage. It's insanely efficient and has more than halved the load on our servers.

You have to tell Varnish what to cache, either explicitely via it's VCL config language, implicitely by having your app send correct HTTP headers. Some things we had to change in our app were: reduced usage of sessions, to reduce need for cookies. Serious filtering of cookies in Varnish (for example: Varnish won't cache any request that contains any cookies, even cookies meant for the browser like Google Analytics). We cleaned up all our HTTP headers, which tell both Varnish and the webbrowser what to cache. We modified our CMS to send a call to Varnish to purge a URL from cache if the content is edited. Etc.

In all regards Varnish has been great for us, since it works well and has taught us a lot about our application's behaviour. As you can tell, I highly recommend it.

First of all, figure out what your actual problem is so you don't waste time on the wrong solution.

Answer 2

If you have clear demarcation between you static and dynamic content then you can use nginx as a reverse proxy. The static content can be served directly by nginx and dynamic can be proxies to Apache. This option will be slightly slower than having a cache like Varnish, as suggest by Martijn, but if RAM is a limitation then I would go this route.

Also if you do use nginx as a reverse proxy make sure to turn off gzip on apache and save a couple of CPU cycles because nginx will be decompressing and recompressing the reponse before returning it to the user.