你认为哪个Web服务器架构更好？

Nginx不提供dynamic内容，它只能与某种后端进行交互，后者可以是Apache或FastCGI进程（可以在另一台主机上运行）。 如果您比较Apache和FastCGI，那么后者更容易configuration，但前者可能更通用。 不过，我有一个印象，大多数情况下，Nginx / FastCGI已经足够好了。 因人而异。

你有什么特别的configuration吗？

PHP将是dynamic内容，因此您不会使用Nginx的反向代理cachingfunction。 如果您有效地使用Nginx作为dynamic内容的负载平衡器，它肯定会更有效率。

如果您正在讨论单个服务器，那么将Nginx置于透明地代理dynamic内容之前将会增加额外的处理层。 虽然可能很小，但技术上会引入额外的开销。 不过，高速caching的性能提升可能会弥补这一点。

对自己的独特情况有信心的唯一方法是运行自己的基准。 Jmeter等实用程序可用于负载testing。

大多数人在大网站上使用1，但2应该是好的。 有基准 ，但大多数是合成的或具体的。

总的来说，它们非常接近，但是我会说nginx更容易设置（或者更好地说，更难以configuration错误），而且它的内存不足。

为什么不用生产中的两个选项来testing您的特定设置？

我看不到另一个引入另一个软件的另一个失败点，这个软件实质上是重复另一个软件的function。 如果您在使用静态内容的Apache时遇到问题，我会首先查看configuration，而不是将其归咎于实际的软件。 阿帕奇是非常受欢迎的原因。

将静态和dynamic分割成两个不同的虚拟主机在Apache（因此在不同的主机名）。

将dynamic主机名指向您的服务器/负载均衡器（“起源”）。

CNAME静态主机名几乎任何CDN，几乎没有问题，并有CDN作为caching代理回到您的来源。

configurationApache正确注意到mod_expiresconfiguration（和etag设置，如果群集）。

由此产生的数量，你的来源曾经实际上看到的静态内容将是如此微不足道的，这将是没有意义的复杂configuration与第二个http服务器。

从技术上讲，如果你是好的，而且你很了解你的框架的http头处理能力，你也可以通过CDN运行dynamic的东西（也应该），但一次只能做一件事。

你会发现，一旦你达到一个特定的级别，你将会转移到apache2-mpm-worker + fcgid for php，在这一点上，你可能只是使用Nginx作为一个单一的解决scheme。

但是，如果您决定从头开始使用CDN，则可以使用CDN，可以考虑将主机名拆分，或者在系统中为静态内容指定单独的域。 虽然static.yourdomain.com是不错的，你用.domain.com设置的任何cookie将被转移到static.yourdomain.com这是一个额外的stream量与静态资源的每个请求的一点点。

Nginx / fastcgi比apache2 / mod_php稍微快一些，大致相当于apache2 / mpm-worker与fcgid。 在这种情况下，简化你的堆栈并只使用Nginx，尽可能考虑使用caching。 记住速度是重要的，服务高stream量有时更重要。 有时候服务100人的速度不及一万人的服务速度。 mod_php5使用prefork不能很好地处理雷鸣的牛群。 如果您的stream量突发，您将不​​得不使用fcgid / fastcgi进行部署。

Nginx / fastcgi引入了一些你不会用apache2 / mod_php5看到的错误，但是这些错误主要涉及到环境variables和php与Nginx的交互方式。 请记住，Nginx的代理是http / 1.0 – 即使Nginx使用http / 1.1与客户端进行通信 – 不支持Nginx和代理之间的keepalive。

这就是说，如果你想坚持使用Apache，mpm-worker + fcgid / php5仍然可以做得很好，如果你将图片内容卸载到CDN上，你就会遇到大多数人可以轻松诊断的情况。 Nginx并不支持mod_rewrite，也有一些模块可以在apache中使用，而Nginx不支持.htaccess指令不支持（尽pipe可以在Nginxconfiguration中模拟）。

如果你习惯于在apache环境下开发，你可能会觉得Nginx很混乱。 如果你从一开始就开发一个项目，你可能会发现今天使用Nginx更容易部署，当你遇到这些问题时，你已经解决了这个问题。 如果你今天用Apache进行部署，然后尝试转换，你可能遇到一些你没有预料到的问题。