Use Nginx for PHP app?

Question

I've been doing research (and testing) for several days on the pros and cons of using Nginx over Apache.

My main question is, is it worth while to use Nginx for a SaaS built on PHP and MySQL?

Just about all of our static files will be served from Amazon S3. That only leaves php and the database for the server to handle.

The server will be a quad core with 8GB of RAM with 10K disks in RAID 10.

I know at launch there won't be much of a difference since the overall traffic load will be fairly low. However, I'd rather plan for the future now, than have to reconfigure our app to work on a completely different web server.

I've tested the app on apache and nginx. Apache was easy to set up since it was pretty much a basic LAMP stack with a few extra packages. With nginx it has been much more work - and I still don't have it set up entirely (at least not something that I would want to push to production). I've been using Nginx .0.8.50, php5.3.3 with php-fpm and APC. Nginx has required compiling several libraries and the config files are not something I'm used to - and still need a great deal of work.

Is it really worth our time to worry about Nginx since most of our app is dynamic?

Thanks in advance!

Answer 1

I wouldn't worry about nginx or any of the other fancy new tools out there until you have a reason to. DO plan your application appropriately (try not to make a giant mess). Things like keeping your static content separate from dynamic, and setting proper apache cache headers will get you a lot farther than deploying tools like nginx and varnish.

Keep good traffic stats - and keep your code & content organized - when you get busy enough to actually need to move to one of these technologies to save real money... you'll be in a position to do so.

Simpler is better. You don't need nginx unless apache is causing you too much overhead. You probably don't need Varnish until your application is being hit with content that could be statically served elsewhere (which you could do other ways as well). That said - I'd be tempted to design for something like Varnish as part of the architecture of the application rather than worry about Apache... but hard to say.

Addendum: I admin some moderately big PHP websites that are extremely mission critical. Money flushes down the toilet when something goes wrong. Some attention to client-side and shared-cache caching, decent web design, and a little bit of shared-session via mysql gets you a long way - unless you have app-logic that's really slow and you really need to separate out static content from your application, you don't need all the new toys, as awesome and tempting as they are. Your bottleneck is most likely your DB in the first place- memcache may even be too much - cache_lite goes a long way too (paying attention to caching -vs- not paying attention is far more important than which caching technology you pick, until you get really big)

Answer 2

This is a bit of a me-too answer, but regardless:

Why bother? The usual argument for using a light-weight web server like nginx is to provide a ton of lightweight threads for serving static content, allowing you to serve more concurrent static content requests per MB of memory.

Since you're off-loading your static content, this isn't a concern.

If (nearly) every request that hits your server is going to be interpreting PHP, you might as well just stick with a well-tuned apache+mod_php+APC.

Answer 3

Well given that you're clearly several manhours in figure out how much your employer pays you an hour and ask yourself if you've saved that much worth of hardware (or ever will).

Getting caught up in the analysis-paralysis of $incumbent vs. $pop-alternative is by far one of the least productive things sysadmins do. Solve the problems you actually have (like the site not being up yet) and if you ever get to a point where you have so much traffic that cdn's, http caches, loadbalancers, and a couple hundred dollars worth of RAM aren't enough then worry about optimizing for that last 10%.

Answer 4

I probably wouldn't bother with something like this, unless I was sure I needed it. I've found that Apache works really well, and has been the best choice for me in all but a few very specific and specialized cases. If Apache was easy to setup, and you've got that configuration working and correct, decide whether you need further optimizations before you perform them.

Do some benchmarking and load testing. Can your current setup manage the anticipated load? If it can, then congratulations, you're already done with this step. If not, is CPU on this box actually your limiting factor (as opposed to RAM, or disk, or network bandwidth, or whatever). Along with the load testing, do some profiling. If you run some benchmarks and you see that PHP is using 98% of the CPU, and Apache is using 1% of the CPU, optimizing the CPU usage from the web server can never buy you more than 1% improvement.