我一直在研究（testing）好几天，讨论在Apache上使用Nginx的优缺点。
我的主要问题是，使用Nginx来构build基于PHP和MySQL的SaaS是值得的吗？
几乎所有的静态文件都将从Amazon S3提供。 只留下PHP和服务器的数据库来处理。
服务器将是一个四核的8GB内存与10K磁盘在RAID 10。
我知道，在启动时，整体的stream量负载会相当低，所以不会有太大的区别。 不过，我宁愿现在计划未来，也不必重新configuration我们的应用程序，以在完全不同的Web服务器上工作。
我已经在apache和nginx上testing了这个应用程序。 Apache很容易build立，因为它基本上是一个基本的LAMP堆栈，有一些额外的软件包。 有了nginx，它已经做得更多了 – 而且我还没有完全build立起来（至less不是我想要推向产品的东西）。 我一直使用Nginx的.0.8.50，php5.3.3与PHP的FPM和APC。 Nginx需要编译几个库，configuration文件不是我习惯的 – 而且还需要大量的工作。
因为我们的大部分应用程序都是dynamic的，是否真的值得我们花时间去担心Nginx？
提前致谢！
除非你有理由，否则我不会担心nginx或任何其他奇特的新工具。 做适当的计划你的应用程序（尽量不要做一个巨大的混乱）。 像保持你的静态内容与dynamic分离，并设置适当的Apachecaching头将比你更多地部署工具，如nginx和varnish。
保持良好的stream量统计 – 并保持您的代码和内容的组织 – 当你忙得足以实际需要移动到这些技术之一，以节省真正的钱…你将有能力这样做。
越简单越好。 你不需要nginx，除非apache导致你太多的开销。 你可能不需要清漆，直到你的应用程序被击中的内容可以静态地在其他地方（你可以做其他的方式）。 这就是说 – 我会试图devise一些像Varnish一样的应用程序架构的一部分，而不是担心Apache …但很难说。
附录：我pipe理一些中等规模的PHP网站，这些网站非常关键。 出现问题时，钱冲洗厕所。 一些关注客户端和共享caching的caching，体面的网页devise，以及一点点的通过mysql的共享会话都会让你有很长的路要走 – 除非你的应用程序逻辑非常慢，你真的需要分离出静态内容从你的应用程序，你不需要所有的新玩具，真棒和诱惑，因为它们是。 你的瓶颈最有可能是你的数据库 – memcache甚至可能太多 – cache_lite也是一个很长的路要走（注意caching） – 不关注远比你select的caching技术更重要，直到你得到真的很大）
这也是我的一个答案，但无论如何：
何必？ 使用像nginx这样的轻量级web服务器的常用参数是提供大量的轻量级线程来提供静态内容，使您能够为每MB内存提供更多并发的静态内容请求。
由于您正在卸载静态内容，因此这不是问题。
如果（几乎）每一个打到你的服务器的请求都要解释PHP，那么你可以坚持一个调整好的apache + mod_php + APC。
那么考虑到你明确了几个人的工作时间，弄清楚你的雇主每小时支付多less钱，并问问自己是否已经节省了那么多的硬件（或者将来）。
陷入分析 – 现行与现在stream行替代瘫痪是目前为止，系统pipe理员所做的最不具生产力的事情之一。 解决你实际遇到的问题（比如网站还没有上线），如果你有一个stream量很大的点，那么httpcaching，负载均衡和几百美元的RAM是不够的，担心最后10％的优化。
除非我确定我需要它，否则我可能不会为这样的事情而烦恼。 我发现Apache运行的非常好，除了一些非常特殊和特殊的情况外，它一直是我的最佳select。 如果Apache易于安装，并且configuration正确且正确，那么在执行之前，请确定是否需要进一步优化。
做一些基准testing和负载testing。 您当前的设置是否可以pipe理预期的负载？ 如果可以，那么恭喜你，你已经完成了这一步。 如果没有，这个盒子上的CPU实际上是你的限制因素（而不是RAM，磁盘或networking带宽，或其他）。 随着负载testing，做一些分析。 如果您运行一些基准testing，并且您看到PHP使用了98％的CPU，并且Apache正在使用CPU的1％，那么优化Web服务器的CPU使用率永远不会让您获得超过1％的改善。