php,and use nginx to serve static filesSo 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.
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)
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.
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.
fastcgi in Nginx/fastcgi you mentioned above? So if someone comes up with a fcgid for Nginx,it'll be the fastest,I guess:)