1. use apache to server dynamic requests that need to be processed by php,and use nginx to serve static files
  2. use nginx to serve all requests

So the key point is: which of them is more efficient in serving dynamic requests(we have no doubt that nginx is much better than apache in serving static files)?


Nginx does not serve dynamic content, it can only talk to some kind of backend, which can be Apache or FastCGI process (which can run on another host). If you compare Apache to FastCGI, then the latter is easier to configure, but the former is, probably, more versatile. I have an impression, though, that for most occasions, Nginx/FastCGI is good enough. YMMV.

  • Apache also need php module to handle php request:LoadModule php5_module modules/libphp5.so,but my problem is not whether Nginx/FastCGI is good enough,it's which is better:Nginx/FastCGI or Apache(fastcgi or php module) – ngache Apr 16 '10 at 15:07
  • I would say that as far as it concerns memory, Nginx/FastCGI should be more efficient under load. If you plan to use Apache without some kind of a front end (Nginx, e.g.), you will need LOTS more of RAM. CPU requirements will hardly be a bottleneck. – minaev Apr 19 '10 at 14:01

Is there any particular configuration you had in mind?

PHP would be dynamic content, as such you would not be using the reverse proxy caching functionality with Nginx. If you effectively used Nginx as a load balancer for dynamic content, it would certainly be more efficient.

If you are talking about a single server, putting Nginx in front to transparentally proxy dynamic content is going to add an additional layer of processing. While likely minute, it would technically introduce additional overhead. Nevertheless, the performance gains from caching would likely make up for that.

The only way to be confident for your unique situation is to run your own benchmarks. A utility such as Jmeter could be used for load testing.

  • Do you have a final answer for:which is better:Nginx/FastCGI or Apache(fastcgi or php module) – ngache Apr 16 '10 at 15:24
  • @ngache: define better first, i.e. how many request per seconds, latency requirements, ratio static/dynamic, required app server(s) to handle the load or not, etc, etc,... you get the idea. It seems to me you like nginx, so go for it, it will be good enough. – Dan Andreatta Apr 16 '10 at 15:49
  • As per my post,I'm only asking about the performance of dynamic requests. – ngache Apr 16 '10 at 16:01
  • 1
    @ngache: oh, then the answer is "it depends". – Dan Andreatta Apr 16 '10 at 16:19

People mostly use 1 on larger sites, but 2 is supposed to be good to. There are benchmarks, but most of them are synthetic or specific.

Overall they are quite close, but I would say nginx is easier to setup (or better to say, harder to configure wrongly) and it is less memory hungry.

Why not test your particular setup with both options in production?


I do not see a point of adding yet another point of failure by introducing another piece of software, which essentially duplicates the functionality of the other one. If you are having issues with Apache serving static content, I would look into the configuration first and not blame it on the actual software. Apache is immensely popular for a reason.


Split the static and dynamic into two different virtual hosts in apache (and therefore at different hostnames).

Point the dynamic hostname at your server/loadbalancer ("origin").

CNAME the static hostname to almost any CDN, barely matters which, and have that CDN act as a caching proxy back to your origin.

Configure apache properly taking note of mod_expires configuration (and etag settings if clustering).

The resulting amount of requests that your origin ever actually sees for static content will be so trivially minuscule that it will be pointless to complicate the config with a second http server.

Technically, if you're good, and you know your framework's http-headers manipulation abilities well, you can run the dynamic stuff through the CDN too (and should), but one thing at a time.


You'll find that once you reach a particular level, you're going to move to apache2-mpm-worker + fcgid for php, at which point, you might as well just use Nginx as a single solution.

You could use a CDN, though, if you decide not to use one from the start, consider making it easy to split off a hostname or make it easy to specify a separate domain for static content in your system. While static.yourdomain.com is nice, any cookies you set with .domain.com will be transferred to static.yourdomain.com which is a tiny bit of extra traffic with each request for a static resource.

Nginx/fastcgi is going to be marginally quicker than apache2/mod_php and roughly equivalent to apache2/mpm-worker with fcgid. Simplify your stack and use only Nginx in this case, consider using caching where you can. Remember speed is important, serving high traffic volumes is sometimes more important. Sometimes serving 100 people very quickly is not as good as serving 10000 people fairly quickly. mod_php5 uses prefork which does not handle the thundering herd very well. If your traffic is bursty, you'll have to deploy with fcgid/fastcgi.

There are some corner cases where Nginx/fastcgi introduces some bugs that you won't see with apache2/mod_php5, but, those are mostly involved with the environment variables and the way php talks with Nginx. Remember that Nginx's proxy is http/1.0 - even though Nginx talks to the client with http/1.1 - keepalives between Nginx and your proxy aren't supported.

That being said, if you wanted to stick with Apache, mpm-worker + fcgid/php5 can still do very well and if you offload your image content to a CDN, you've got a situation that most people can easily diagnose. Nginx doesn't support mod_rewrite in the same manner, there are modules you might use in apache that you can't use with Nginx, .htaccess directives are not supported (though can be emulated in the Nginx config).

If you are used to developing in an apache environment, you might find Nginx to be confusing. If you are developing a project from the start, you might find it easier to deploy today with Nginx and when you hit those issues, you'll have already addressed them. If you deploy with Apache today, and later try to convert, you might run into some issues that you didn't anticipate.

  • What's the difference between normal cgi mode and fcgid? – ngache Apr 16 '10 at 18:11
  • fastcgi is one implementation of apache/nginx -> php. fcgid is an alternative which I've found to be quicker and isn't really any more difficult to set up. httpd.apache.org/mod_fcgid – deleted Apr 16 '10 at 18:14
  • What's the module for fastcgi in Nginx/fastcgi you mentioned above? So if someone comes up with a fcgid for Nginx,it'll be the fastest,I guess:) – ngache Apr 16 '10 at 18:24
  • you can use fcgid or fastcgi with nginx. Fastest is subjective and usually not the issue. Your code/database will often be your bottleneck more than the communication of your webserver to the php engine. If performance is that much of a factor, removing php will give you a much larger performance gain. Make sure you zend encode your code so that it doesn't need to be interpreted, use an opcode cache, avoid doing cross-server connections. Will 5 transactions per second really impact your design that much? – deleted Apr 16 '10 at 19:03
  • 1
    Zend Optimizer 'compiles' your phpcode into bytecode that doesn't need to be interpreted on each pageload. apc, xcache, eaccelerator are all opcode caches which cache the bytecode, preventing the need for the code to be interpreted on each pageload. You could also use facebook's hiphop. The 5 transactions per second refers to the minimal difference between different implementations. Sometimes switching to the 'best' platform as suggested by a benchmark yields a minimal improvement in real, production use. – deleted Apr 17 '10 at 4:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy