php 项目性能优化

C.2. 类装载
做过Zend Framework 应用性能调优的人都知道，Zend Framework 中类装载的开销是相当大的。从各组件对应的大量类文件，到类名与文件系统非唯一对应的插件的引入，大量include_once和 require_once调用可能导致严重的性能问题。这章将提供一些具体的策略来解决这些问题。
 C.2.1. 如何优化include_path?
提高类装载速度的一个优化策略是合理安排include_path。具体而言，你应该做四件事情：使用绝对路径（或绝对路径的相对路径[原文：paths relative to absolute paths]）；减少包含路径数量；ZF库的路径要尽量靠前；只在include_path最后包含当前路径。
 C.2.1.1. 使用绝对路径
尽管这看起来是一个微不足道的优化，然而如果不这么做，PHP的realpath缓存可能就无法发挥作用，结果导致opcode缓存的效果与你的期望大相径庭。
做到这一点有两个简单的途径。第一种是在php.ini、httpd.conf或.htaccess 中硬编码那些包含路径。第二种是在设置include_path时调用PHP的realpath()函数：
 
$paths = array(
realpath(dirname(__FILE__) . '/../library'),
'.',
);
set_include_path(implode(PATH_SEPARATOR, $paths);
你也可以使用相对路径——如果它是一个绝对路径的相对路径：

define('APPLICATION_PATH', realpath(dirname(__FILE__)));
$paths = array(
APPLICATION_PATH . '/../library'),
'.',
);
set_include_path(implode(PATH_SEPARATOR, $paths);
尽管如此，对一个相对路径调用realpath()也很方便。
C.2.1.2. 减少包含路径的数量
包含路径将按照它们的出现顺序逐个扫描。显而易见，如果文件在第一个路径下的查找速度要远远快于它在最后一个路径。因此，一个明显的改善方法是减少 include_path中的路径数目，只包含必需的路径。仔细检查自己在include_path中定义的每一个路径，确保应用用到了该路径下的代码， 如果没有，则删除。
 另外一个优化方法是合并路径。例如，Zend Framework 遵循PEAR 的命名规范，因此，如果应用同时也使用了PEAR 库（或其它遵循PEAR 命名规范的框架或组件库），则可以把它们放在相同的包含路径下。通常，这只需要在一个公共目录下为各个库建立一个符号链接。
 C.2.1.3. 尽早定义Zend Framework库的路径
除了上面的建议，另外一个优化方法是尽量把Zend Framework库的路径放在include_path的前面。在大部分情况下，它应该是include_path中的第一个路径。这样可以保证Zend Framework自身的文件可以在第一次扫描中命中。
 C.2.1.4. 把当前路径放在最后或去掉
大部分include_path的例子都包含当前路径，或‘.’。这可以方便脚本包含当前目录下的文件。并且在这些例子中，当前路径通常是在 include_path的开头——即首先尝试当前路径。对于Zend Framework应用，这通常不是开发者所期望的，当前路径放在包含路径的最后或许更适合一些。
 Example C.1. 示例: 优化include_path
让我们把上述建议综合在一起。假设我们同时使用Zend Framework 和一些PEAR库——如PHPUnit和Archive_Tar库，并且偶尔也需要从当前目录包含文件。
 首先，我们在项目中建立一个库目录。在这个目录中，为Zend Framework库和其它PEAR库建立符号链接：

library
Archive/
PEAR/
PHPUnit/
Zend/
如果需要的话，还可以在此建立项目自身的库目录，这对那些共享库毫无影响。
接下来，我们将在public/index.php 文件中创建包含路径。它会在所有请求中执行生效，不需要在别的地方再次设置。
我们将采用上面的建议：使用通过realpath()获取的绝对路径；把Zend Framework库路径放在前边；合并包含路径；把当前路径放在最后。事实上，示例做得非常漂亮——仅用了两个路径。
 
$paths = array(
realpath(dirname(__FILE__) . '/../library'),
'.'
);
set_include_path(implode(PATH_SEPARATOR, $paths));

C.2.2. 如何消除非必要的require_once语句
延迟载入是一项仅在需要时载入类的优化技术。——比如实例化一个对象、调用静态类的方法或者引用类的常量或静态属性。PHP通过自动载入机制实现延迟载入，开发者需要定义回调函数，将类名映射到相应的类文件。
 然而，如果你在库中仍然使用require_once，那么自动载入的效果就要大打折扣——在Zend Framework中更是如此。因此，现在的问题是：如何消除这些require_once调用，从而发挥自动载入机制的最大性能？
 C.2.2.1. 使用find和sed去除require_once调用
去除require_once 的一个简便方法是联合使用unix工具find和sed，把每个require_once 语句转换为注释。可以使用下面的命令(%是shell提示符)：
 
% cd path/to/ZendFramework/library
% find . -name '*.php' -print0 | xargs -0
sed --regexp-extended --in-place 's/(require_once)/// 1/g'
这一行命令（因为阅读方便分为两行）遍历每一个PHP文件，将'require_once' 替换为'// require_once'，高效地将每个require_once调用注释掉。
 这行命令可以方便地加入到一个自动部署或发布工具中，帮助提升产品的性能。不过需要注意的是，如果你使用了该技术，你就必须使用自动载入功能，这可以在项目的"public/index.php"文件中通过下面代码实现：
 
require_once 'Zend/Loader.php'; // one require_once is still necessary
Zend_Loader::registerAutoload();
C.2.3. 如何加快插件的载入
许多组件都支持插件，开发者可以自己开发插件和对应组件协同工作，也可以覆写存在于Zend Framework包中的标准插件。插件给框架增加了灵活性，但是为此付出的代价是：插件的载入需要耗费大量资源。
 插件载入器允许开发者注册类前缀/路径对，从而为插件指定非标准的类文件搜索路径。每个前缀允许关联多个路径。在内部，插件载入器首先遍历所有类前缀获 取该类前缀关联的路径，然后再遍历这些路径查找文件，然后读入文件，测试查找的类是否已经找到。可以想象，这将产生很多对文件系统的stat调用。
 把这个过程乘以使用PluginLoader的组件数，你就可以知道该问题的影响范围了。截止到本文写作时，下面列举的组件使用了PluginLoader： •Zend_Controller_Action_HelperBroker: 助手
•Zend_Dojo: 视图助手，form元素和装饰器
•Zend_File_Transfer: 适配器
•Zend_Filter_Inflector: 过滤器（ViewRenderer动作助手和Zend_Layout使用）
•Zend_Filter_Input: 过滤器和验证器（validators）
•Zend_Form: 元素，验证器，过滤器，装饰器，验证码（captcha），文件转换适配器
•Zend_Paginator: 适配器
•Zend_View: 助手，过滤器

如何减少这些调用的次数呢？
C.2.3.1. 使用插件载入器的包含文件缓存
Zend Framework 1.7.0为PluginLoader增加了一个包含文件缓存。该功能将记录插件的类文件路径，并构造"include_once"语句写入一个文件，从 而可以在启动文件中包含该文件。尽管这么做将使你的代码增加很多include_once调用，但是它可以让插件载入器运行的更快。
 PluginLoader的文档：includes a complete example of its use.

C.3. 国际化(i18n)和本地化(l10n)
国际化和本地化站点是扩展用户的好方法，它保证访问者可以获得所需的信息。然而，它也经常会带来一些性能问题。下面这些策略可以用于降低国际化和本地化带来的负担。
 
C.3.1. 该使用哪个翻译适配器
各种翻译适配器千差万别，有的以功能丰富见长，有的以性能卓越著称。除了因业务限制而只能选择特定适配器之外，该如何选择一个高效率的适配器呢？
 
C.3.1.1. 使用非-XML翻译适配器获取最快的速度
Zend Framework中包含了许多翻译适配器。然而它们多半使用XML格式，这会导致内存和性能的开销。幸运的是，也有一些适配器是基于能够高效解析的其它格式。按照速度从快到慢的顺序，它们是：
 · Array：这是最快的，它将在包含时被直接解析为PHP的原生格式。
· CSV：使用fgetcsv()解析CSV文件，并转化为PHP的原生格式。
· INI：使用parse_ini_file()解析INI文件，并转化为PHP的原生格式。它的性能和CSV差不多。
· Gettext：Zend Framework中的gettext适配器没有使用gettext扩展，因为该扩展是非线程安全的，并且不能在一个服务器上指定多个locale。因 此，它比直接使用gettext扩展要慢，不过gettext格式是二进制的，比解析XML要快。
 如果高性能是你的一个关注点的话，建议使用上述的某个适配器。
 
C.3.2. 如何使翻译和本地化更快
也许因为商业因素，你只能使用基于XML的翻译适配器。或者想让程序更加高效，或者想让本地化操作更快。有什么办法呢？
 
C.3.2.1. 使用翻译和本地化缓存
Zend_Translate和Zend_Locale都实现了缓存功能，它可以明显地提升性能。通常情况下，性能瓶颈在于读入文件，而不是实际的查找操作，使用缓存可以避免翻译和本地化文件的重复读取。
 你可以从下面链接中进一步了解翻译和本地化缓存的内容：
· Zend_Translate adapter caching
· Zend_Locale caching
 
C.4. 视图渲染
如果使用Zend Framework的MVC框架，你可能会使用Zend_View组件。相对于其它视图或模板引擎，Zend_View是相当高效的。因为直接用PHP编 写视图脚本，就没有编译自定义标记的负担，也不需要担心编译后脚本的优化。当然， Zend_View也存在自己的问题：扩展的代价很大（视图助手），如果通过许多视图助手来完成关键功能，将会导致很大的性能开销。
 
C.4.1. 如何加快视图助手的解析
Zend_View中的大部分方法实际上都是通过助手系统的重载来实现的。它赋予Zend_View极大的灵活性，不需要扩展Zend_View，提供应 用所需的助手方法就可以，开发者在单独的类中定义助手方法，然后就可以像调用定义在Zend_View中的方法那样使用助手方法。这样既可以保持视图对象 的简单性，也可以保证助手只在需要时被创建。
 在内部，Zend_View通过插件载入器查找助手类文件。这意味着每一次调用助手，Zend_View需要把助手名字传给插件载入器，由它决定类名， 如果未载入则载入助手，然后返回实例化的对象。因为Zend_View在内部缓存了已经加载的助手，所以下次再使用这个助手时，速度将会快很多，然而，如 果应用中使用了很多助手，这个过程对系统性能的影响可能会很大。
 那接下来的问题是：如何加速助手的解析？
 
C.4.1.1. 使用PluginLoader的包含文件缓存功能
这是最简单经济的方法，具体见C.2.3.1中所述。曾经有实验表明，这个技术在没有opcode缓存情形下可以提高25-30%的性能，如果有opcode缓存，则可以提高到40-65%。
 
C.4.1.2. 扩展Zend_View来提供常用助手方法
另外一个提高性能的方法是扩展Zend_View，在子类中手动增加应用常用的助手方法。这些助手方法可以简单地作为一个代理，实例化一个相应助手类完成任务，当然也可以自己实现任务的所有操作。
 class My_View extends Zend_View{ /** * @var array Registry of helper classes used */ protected $_localHelperObjects = array(); /** * Proxy to url view helper * * @param array $urlOptions Options passed to the assemble method of the Route object. * @param mixed $name The name of a Route to use. If null it will use the current Route * @param bool $reset Whether or not to reset the route defaults with those provided * @return string Url for the link href attribute. */ public function url(array $urlOptions = array(), $name = null, $reset = false, $encode = true ) { if (!array_key_exists('url', $this->_localHelperObjects)) { $this->_localHelperObjects['url'] = new Zend_View_Helper_Url(); $this->_localHelperObjects['url']->setView($view); } $helper = $this->_localHelperObjects['url']; return $helper->url($urlOptions, $name, $reset, $encode); } /** * Echo a message * * Direct implementation. * * @param string $string * @return string */ public function message($string) { return "" . $this->escape($message) . "n"; }}
无论哪种方式，该方法将大量降低助手系统的性能消耗，它完全避免了插件载入器的调用，同时还充分利用了自动加载机制和按需加载的特性。
 
C.4.2. 如何提高区域视图（view partials）性能
如果开发者在应用中大量使用区域（partials），那么他会经常发现partial() 视图助手会因为克隆视图对象而产生性能瓶颈。有办法提高它的速度吗？
 
C.4.2.1. 仅在真正需要时使用partial()
partial()视图助手接收三个参数：
· $name: 视图脚本的名字
· $module: 视图脚本所在的模块名，或者当没有第三个参数且是一个对象或数组时，它将作为$model参数。
· $model: 数组或对象，作为干净的数据赋值给视图，用于解析区域视图。
partial()的强大之处在于第二与第三个参数。$module参数允许临时加入指定模块的视图路径，从而解析该模块下的区域视图脚本；$model参数允许你显式地为区域视图指定变量。如果你根本没有用到这两个参数，那么请用render()代替！
 基本上，除非你需要为区域视图传入变量并需要一个干净的变量环境，或者渲染另外一个MVC模块的视图，你没有必要使用partial()。相反，你应该使用Zend_View内置的render()方法渲染视图。
 
C.4.3. 如何提高action()视图助手性能
1.5.0版本引入了action()视图助手，允许开发者分发一个MVC动作并捕获它的输出。它向DRY原则迈近了一大步，促进了代码的复用。但是这也 是一个代价高昂的操作。在action()视图助手内部，它会克隆请求和响应对象，调用分发器，然后调用对应的控制器和动作等等。
 如何提高它的速度呢？
 
C.4.3.1. 尽量使用ActionStack代替
与action()视图助手同时加入ZF的动作堆栈，由一个动作助手和前端控制器插件组成。它允许你将分发周期中需要调用的附加动作压入一个栈中。如果你 在布局视图脚本中使用了action()，它可以用动作堆栈替换，完成视图的渲染，实现响应片段的分离。作为例子，你可以像下面那样实现一个 dispatchLoopStartup() 插件，为每个页面添加一个登录表单输入框：
 class LoginPlugin extends Zend_Controller_Plugin_Abstract{ protected $_stack; public function dispatchLoopStartup( Zend_Controller_Request_Abstract $request ) { $stack = $this->getStack(); $loginRequest = new Zend_Controller_Request_Simple(); $loginRequest->setControllerName('user') ->setActionName('index') ->setParam('responseSegment', 'login'); $stack->pushStack($loginRequest); } public function getStack() { if (null === $this->_stack) { $front = Zend_Controller_Front::getInstance(); if (!$front->hasPlugin('Zend_Controller_Plugin_ActionStack')) { $stack = new Zend_Controller_Plugin_ActionStack(); $front->registerPlugin($stack); } else { $stack = $front->getPlugin('ActionStack') } $this->_stack = $stack; } return $this->_stack; }}
 然后UserController::indexAction()方法就可以通过responseSegment参数指定渲染哪个响应片段。在布局脚本中，你可以简单地输出该响应片段：
 layout()->login ?>
尽管ActionStack需要一个分发周期，但是它比action()视图助手效率要高，因为它不需要克隆对象及重置它们的状态。此外，它可以确保所有的pre/post分发插件会被调用，如果你是通过前端控制器插件实现ACL，那么这一点就显得特别重要。
 
C.4.3.2. 查询模型时使用视图助手代替action()
大部分情况下，使用action()是小题大做。如果大部分的业务逻辑都封装在模型中，而你只是简单地查询模型，并将结果传递给视图脚本的话，通过一个视图助手获取模型，查询数据，完成相应的操作，将是一个更高效简洁的方法。
 作为一个例子，考虑下面的控制器动作和视图脚本：
class BugController extends Zend_Controller_Action{ public function listAction() { $model = new Bug(); $this->view->bugs = $model->fetchActive(); }} // bug/list.phtml:echo "n";foreach ($this->bugs as $bug) { printf("•%s: %sn", $this->escape($bug->id), $this->escape($bug->summary));
•
}echo "n";
使用action()，将像下面这样调用：
action('list', 'bug') ?>
这可以重构为通过视图助手实现，如下所示：
class My_View_Helper_BugList extends Zend_View_Helper_Abstract{ public function direct() { $model = new Bug(); $html = "n"; foreach ($model->fetchActive() as $bug) { $html .= sprintf( "•%s: %sn",
•
 $this->view->escape($bug->id), $this->view->escape($bug->summary) ); } $html .= "n"; return $html; }}
 然后像下面这样调用助手：
bugList() ?>
这么做有两个好处：消除了action()助手的开销，并且该API更易于理解。