优化顺序
首先:良好的系统设计
然后:代码与脚本
最后:着眼PHP本身
扩展阅读
展开/折起 - 头部

PHP系统性能优化原则

这里记载的是我觉得在做优化工作时应该秉承的原则与步骤,不是具体的优化方法(优化方法google有很多)。

一提到性能优化,就会听到双引号、单引号、三等号之类的,我认为如果按着这个去做,就有点舍本逐末了。

做优化之前,先说一下我对系统设计目标的理解

其中,第二位与第三位的顺序肯定有人提反对意见,因为我一个朋友就提过,但一段时间后,他也同意了可维护要比性能更重要些。 这里只能说是我个人的经验,没有办法像数学公式证明那样一步步的给出证明过程。

优化顺序

这里从PHP程序本身来说下性能

首先:良好的系统设计

我敢保证,对于Web系统,绝大多数情况下PHP本身不会成为性能瓶颈。瓶颈经常是系统设计、业务逻辑梳理有问题。 如果系统设计不合理,就算我们把所有的双引号替成单引号也无济于事。

这里举个例子,我们一个系统设计初期没有很多对cache访问进行规划,单次请求中cache访问次数过多,出现 还不如访问数据库快的情况。(因此,cache应该像关系表那样从一开始便进行精心设计)

然后:代码与脚本

这一步也比较关键,实际中经常会碰到过两类问题:

其中第二类问题大家经常忽略。前不久我们访问一个内部服务(依赖其提供的sdk),性能怎么都提不上去。最后 我把sdk中所有的类都合并到一个文件中,性能瞬时提高了10%。这是脚本过多的问题,我们解决了,但是脚本过大的 问题我们没有解决,因为就算合并后,代码也是有几千行,在xhprof呈现的性能report里仍然是一个大大的方框。

对于脚本过大,再提个大家可能不太容易注意到的建议:把controller/action设计改成action设计, 这样可以避免超大controller的出现,从而提升部分性能。

对于单引号、双引号问题,我建议在项目中保持统一即可。要么单双分开用,要么统一双引号,这不会 成为性能的瓶颈所在。

对于三等号、双等号问题,我建议主要从程序逻辑正确性这方面来考虑如何使用。

说到脚本了,提个长久一来的疑问:smarty等有必要存在么?php的原生模板语法不是更好么?

最后:着眼PHP本身

如果系统性能还是不理想,则需要从服务器环境本身来考虑考虑了。

做了这么多年web,我一直相信一点——PHP本身很难成为性能瓶颈所在。

扩展阅读

By RandyChen

架构也分通用的,私有的,一般也只有围绕所在业务的架构才能性能和扩展性兼备。

autoload是必须重视的,对核心库,将这类类集中在一个文件,自动合并可以考虑。yii这么做的,但它的简单,因为它发布了就不会变化。

另外php本身序列化,包括json序列化,都很消耗cpu。一般而言,到一定规模以后重点关注的肯定不是内存,而是cpu。利用好trace观测systime的使用很关键。

还有点就是异步化,io异步,当然这个动作稍微大一些。

2013-05-10

知识共享许可协议 本作品采用知识共享署名 3.0 未本地化版本许可协议进行许可。
comments powered by Disqus