爱吃鱼的东仔

还记得05年刚开始接触Web服务器的时候，Web服务一直都是用的Apache，一次偶然的机会，在一篇博文中看到了Nginx这个高大上的东西，更高的负载能力、更高并发支持、更低资源占用率，这个俄国人开发的轻量级Web服务应用一下就把我折腾的兴趣给勾了起来。从此一发不可收拾，把所有自己用的跟客户用的服务器上全部换成Nginx，看着内存占用一下少了一大截，心里满满的成就感啊！这年头服务器不使用Nginx出门都不好意思跟同行打招呼！

这些年来的陪伴，有Nginx的日子并不孤单，虽然很多应用都要求配置ReWrite规则，而且官方提供的文档全是关于Apache的，但使用Nginx配置规则也可以完美实现，那就完全没有理由不使用Nginx吧。本来以为找到了终极解决方案，直到前不久的一天使用 magento建了一个外贸站，让我不得不重新思考是Nginx还是Apache的问题了。

虽然这件事是由搭建magento外贸站而起，但其实跟magento程序没有半毛钱关系，不得不承认magento是套相当不错的外贸商城程序。当时服务器环境照样是用的Nginx配合PHP-FPM做的运行环境，网站搭建也都很顺利，然后把服务器交接给客户后，客户也相当的满意。

过了不到两天，客户打电话过来说是服务器出问题了，网站打开奇慢无比，要等好半天才能显示出来页面。第一反应感觉是网络问题，因为做外贸站，所以服务器放在了美国，PING了一下，响应速度还算正常，丢包也不严重，基本排除。然后打开Chrome的调试，发现页面的Waiting(TTFB)时间奇长，打开网站首页的时候竟然长达25秒（注意，这里是秒，不是毫秒）。

当时整个人都感觉不好了，这是个啥情况，什么样的程序要执行这么长的时间才出结果。看了下客户添加的商品，也不是太多，不到100件，又看了下数据库，也没有特别大的表。最后去看服务器的资源占用率，我了个去，一刷页面，CPU占用率直接跑到将近30%，php-fpm跟mysqld两个进程来回的跳。

问客户这两天做什么特别的操作没，客户说只是安装了一个新的模板，别的也没干什么，感觉完全莫名奇妙的就出这问题了。然后我就怀疑是magento程序有BUG，会占用大量的CPU，但客户坚持要用这套程序来跑他们的商城，而且服务器的CPU还有不少的剩余，只好硬着头皮开始对PHP的性能进行优化了。

折腾了整整一个晚上，把能想到的办法都用上了，总算把这个Waiting的时间缩短到了13秒左右，但这肯定远远不行，用户体验太差了，第一次打开一个网站，谁都不可能会等这么长时间。无奈，只好想其他办法了，一度怀疑是程序让客户改坏掉了，打算第二天找客户协商重新安装一遍程序。

第二天早上到公司，客户还没有上班，就又上服务器开始折腾，一边继续网上啃资料，无意中又看到了有人在博客里推荐LANMP（LINUX+APACHE+NGINX+MYSQL+PHP）的一键安装包，心里又闪过个念头，是不是Nginx执行PHP的效率不行啊，因为网站打开虽然很慢，但服务器的CPU使用率一直没有超过50%。索性又在服务器上配置了一个Apache环境把网站迁移到上面去运行了下，结果有点出乎意料，这次Waiting的时间降到了8秒左右。虽然还是久到不能接受，但比Nginx有了很大的改善。

终于把客户等上线了，客户同意重新安装程序，但要求商品数据不能丢失！这就好办了，备份好数据库后，重新安装了一遍magento，再次访问，秒开！说明程序本身是没有问题了，然后把备份的数据库导入到新的程序里，打开依然很快，总算松了口气！心里想，肯定是客户自己把程序改坏了，最后把模板文件跟客户要了过来，打算装完后交接给客户的，结果模板文件一弄好，网站又慢了下来，看来问题的罪魁祸首是这套模板啊！！！仔细研究了一下用户的提供模板文件发现里面的一些插件包含了大量的数据库操作，而且很多都是嵌套调用的！打开首页光执行的插件就有几十个，有上百次的数据库操作，我也是醉了！！

给客户解释清楚了以后，客户重新提供了一套模板，换上去一切OK！

客户的问题是解决了，但也发现了新的问题，就是Nginx执行PHP的效率问题，从客户的这次极端情况的表现来看，Nginx执行PHP的效率跟Apache还是有一定的差距的！又爬了一些国外的技术论坛，也有不少人提到过这个问题，这也是后来会出来LANMP包的原因，让Nginx做前端，使用Apache来解析执行PHP文件。

但个人感觉这么做有点多此一举，特别是对于单台服务器来说，意义真的不大，既然都已经部署了Apache了，直接使用不好么，单台服务器其实CPU跟磁盘性能会比Apache更早的达到性能瓶颈。除非你做的是服务器集群，使用Nginx做前端来转发后端的服务请求，或者是提供纯静态文件的Web服务，才能真正体会到Nginx的强大。普通应用环境下，两者的性能差别基本上可以忽略。