PHP性能杂谈

PHP之父Rasmus Lerdorf昨日刚发布了一个叫做《 PHP Performance》的Online PPT，深入浅出，简单直白，以WordPress为例详细解说了优化的方法和相关的工具（strace,  Callgrind, Xdebug,  xhprof等），最后总结中有两点让我深有同感：一是说性能实际上是灵活性和成本之间的权衡取舍，另外一个则是真正的去看待性能问题，应该是面向架构（Real performance is architecture-driven）。

我自己用过好几种编程语言进行企业项目开发，一直以为，对语言的选择应该基于应用场景和业务需求等，与是不是真的OO，性能高不高，代码结构是不是够敏捷等其实没有太多关系。比如频繁更新页面的推广活动，那自然是PHP/ASP之流合适，电子商务等需要事务、安全、稳定的 Web应用使用 Java，有较多自定义行为（略有差异于系统自身实现）的桌面应用使用VC等等。 而语言的性能差异，往往并不是我们所需要去关心的。 印度人做项目时满足用户性能指标的方式往往是告诉用户什么配置的机器能达到这个指标。这是因为重构 算法让代码的性能翻倍往往远不如将CPU换成多核，内存加个几G来得简单、快捷和廉价。

应该说，PHP从性能上来说是有一些先天劣势的（事实上PHP在语言性能排行榜当中确实不太靠前），每次运行必须重新编译就是一个巨大的成本，从Rasmus的第一个优化就是安装 APC就可以看出来这一点。嗯，是的，十分庆幸，我们有 APC、 eAccelerator、 XCache等优秀的op-code缓存帮助我们解决了这个PHP最大的性能问题。紧跟其后的一个重要性能问题是由OOP引入的，事实上PHP 5直到PHP 5.2才得到了广泛的应用，因为PHP 5.2在面向对象的开发方面性能大为提高，已经逼近了函数式编程的性能水准。但时至今日，也依然有一些性能障碍难以解决，比如说由于动态语言的特性，PHP即使有op-code cache，也需要在每次请求的时候重新建立常量列表、可调用函数列表、可调用类列表。 这对于大型企业项目来说，简直是个噩梦。而PHP变量对内存利用的低下也是一个进行大数据量处理时会碰到的严肃问题，资深的PHPer能通过pack指令来解决它，但这真的很不优雅，充满着无奈。（你知道一个100万个数字的数组在PHP中占用多少个字节吗？如果是同样数据量的二维数组呢？ 查过这个数字的Java程序员和C/C++程序员都用一种怜悯的眼神看着PHPer）

但，世界上最大的SNS网站，正在挑战Google的Facebook正是用的PHP！而他们能用PHP做到这样的规模，恰恰就是和“Real performance is architecture-driven”相互呼应的“Languages's don't Scale, Architecture Scale”。所以说，“PHP is rarely the bottleneck”，性能的关键在于，你的项目是怎么架构的。