使用 Zend Opcache 加速 PHP

找到的较好的资料，转载自以下网站，里面有较多linux运维资料，做个记录

http://www.songyawei.cn/tag/opcache

http://blog.sae.sina.com.cn/archives/2353

Optimizer+ 是 Zend 开发的闭源但可以免费使用的 PHP 优化加速组件，是第一个也是最快的 opcode 缓存工具。现在，Zend 科技公司将 Optimizer+ 在 PHP License 下开源成为 Zend Opcache。

Zend OPcache 通过 opcode 缓存和优化提供更快的 PHP 执行过程。它将预编译的脚本文件存储在共享内存中供以后使用，从而避免了从磁盘读取代码并进行编译的时间消耗。同时，它还应用了一些代码优化模式，使得代码执行更快。

1. 什么是 opcode 缓存？

当解释器完成对脚本代码的分析后，便将它们生成可以直接运行的中间代码，也称为操作码（Operate Code，opcode）。Opcode cache 的目地是避免重复编译，减少 CPU 和内存开销。如果动态内容的性能瓶颈不在于 CPU 和内存，而在于 I/O 操作，比如数据库查询带来的磁盘 I/O 开销，那么 opcode cache 的性能提升是非常有限的。但是既然 opcode cache 能带来 CPU 和内存开销的降低，这总归是好事 —— 本着环保的态度，也应该尽量减少消耗不是？ 


现代操作码缓存器（Optimizer+，APC2.0+，其他）使用共享内存进行存储，并且可以直接从中执行文件，而不用在执行前“反序列化”代码。这将带来显着的性能加速，通常降低了整体服务器的内存消耗，而且很少有缺点。

2. Optimizer+ 与 APC 的优缺点对比

Optimizer+ 于 2013年3月中旬改名为 Opcache。

根据 PHP wiki 上的讨论，Zend Opcache 即将整合到 php 5.5 中。作为 APC 的竞争对手，新生的
Zend Opcache 很有可能取代 APC 的位置，虽然 OptimizerPlus 没有象 APC 那样的 user cache 功能。

OPTIMIZER+ 相对 APC 的优点

性能。根据测试，Zend Optimizer+ 始终优于 APC。随代码差异，每秒钟处理的请求数高 5~20%。Google doc 上记录的测试结果中，WordPress
2.1.1（不知道为什么不用个新版本的 WP 来测试），性能提高约 8%。理论上来说，对于 WP 3.5.1，性能应该也能得到大约 5~10% 的提升吧。对于运行 WordPress 的服务器而言，使用 Optimizer+ 可以显著降低 CPU 使用率和提高页面加载速度（graphics
here）。
支持新的 PHP 版本。Zend 和 PHP 社区都会帮助 Optimizer+ 能够支持最新版本的 PHP。
可靠性。Optimizer+ 拥有可选的损坏检测能力，可以防止因数据损坏而导致的服务器崩溃。
更好的兼容性。PHP 社区打算让 Optimizer+ 与社区支持的所有 PHP 版本相兼容。

APC 相对 OPTIMIZER+ 的优势

APC 有数据缓存 API，而 Optimizer+ 没有。
APC 能够回收旧的无效的脚本占用的内存。APC 有内存管理器，可以将那些不再使用的脚本关联的内存进行回收。而 Optimizer+ 不同，它将这样的内存标记为“脏的”，但并不会回收它们。一旦“脏的”内存占用配置阈值的百分比达到一定值，Optimizer+ 就将自己重新启动。这种行为在稳定性上既有优势也有劣势。

3. 使用 Zend Opcode

现在已经可以使用 Zend Opcache 替代 APC 作为 PHP 优化加速工具了。目前的 Zend Opcode 兼容 PHP 5.2.*、5.3.*、5.4.* 和 PHP-5.5 开发版。不过，将来会取消对 PHP 5.2 的支持。

注意：Zend Opcache 与 eaccelerator 相冲突。要安装 Zend Opcache，可能需要先卸载 eaccelerator —— 如果你用了这个加速模块的话。

从源码安装并配置¶

Zend Opcache 的源代码托管在 github 上，目前还是叫做 ZendOptimizerPlus。

安装步骤详见其 README 文件。

注意：
最好在本地虚拟机里测试之后再部署到自己的服务器上；
安装前最好先删除 eacceleratro、xcache 或 apc 等组件。

顺便说一句，从源码编译安装时需要用到 php-devel。README 中快速安装一节的开头就用到，

1	$PHP_DIR/bin/phpize

如果不清楚 phpize 的路径，可以，

1	whereis phpize

README 文件中也有相应的推荐优化设置。

从 REMI 源安装并配置¶

我不喜欢从源码编译安装程序，一个是水平有限，一个就是怕麻烦。下面介绍从 remi 安装源安装 Zend Opcache，以 CentOS 上的操作为例，基于我的
VPS 的配置。

remi 社区已经提供了 Zend Opcache 的安装包，可以直接 yum 安装。当然，前提是已经配置使用了 remi 的安装源。如果没有，可以参考这里。提醒一下，remi 安装源上的 PHP 已经是 5.4 版本了。

鉴于有人测试说 WordPress 在 PHP 5.4 上的性能要优于在 PHP 5.3 上的性能（10% faster andlower
ram consuming），顺便升级一下 PHP 也不是什么坏事。

操作步骤：
配置使用 remi 安装源。已有则跳过。
删除 eaccelerator、xcache、apc：

1	yum remove php–eaccelerator php–xcache php–apcu

没有使用则跳过。

3.对系统执行升级：

1	yum update

目的是根据 remi 安装源的状态升级当前的 php 等软件到 remi 支持的最新版本。此时，可以看到系统有类似下面的输出：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Updating   : php–common–5.4.14–1.el6.remi.i686                                                        1/26 WARNING : These php–* RPM are not official Fedora / Red Hat build and overrides the official ones. Don‘t file bugs on Fedora Project nor Red Hat. Use dedicated forums http://forums.famillecollet.com/ warning: /etc/php.ini created as /etc/php.ini.rpmnew   Updating   : mysql-libs-5.5.31-1.el6.remi.i686                                                         2/26 WARNING : This MySQL RPM is not an official Fedora / Red Hat build and it overrides the official one. Don’t file bugs on Fedora Project nor Red Hat. Use dedicated forums http://forums.famillecollet.com/ warning: /etc/my.cnf created as /etc/my.cnf.rpmnew

表示我们现在要从 Fedora / Red Hat 的版本迁移到 Remi 版本了，所以不要去 Fedora / Red Hat 寻求帮助了。呵呵，貌似出问题都是在网上找，还真是很少到官方论坛里提问。像我这样的入门级用户，也不会遇到那么深度的问题。

4.安装 Zend Opcache（pecl 版本）：

1	yum install php–pecl–zendopcache

安装时产生的 opcache 的配置文件位于默认的 

/etc/php.d

 目录中：

1 2	opcache–default.blacklist opcache.ini

这个配置文件采用的基本就是 README 中的推荐设置，只有几个地方需要修改。

1	vi /etc/php.d/opcache.ini

对照如下推荐配置修改并保存即可：

1 2 3 4 5 6

opcache.memory_consumption=128 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=4000 opcache.revalidate_freq=60 opcache.fast_shutdown=1 opcache.enable_cli=1

5.不需要修改 php.ini 配置，重起 Apache 服务使之生效：

1	service httpd restart

查询一下看看是否正确启动了：

1

php –v

输出结果类似于：

1 2 3 4

HP 5.4.14 (cli) (built: Apr 11 2013 11:04:35) Copyright (c) 1997–2013 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998–2013 Zend Technologies     with Zend OPcache v7.0.1, Copyright (c) 1999–2013, by Zend Technologies

4. 体会

PHP 上有不少 opcode cache 组件，如 APC、eAccelerator、XCache 等。（参见 Wikipedia 上的 PHP accelerators 列表。）看 PHP wiki 上的意思，这个新引入的 Zend Opcache
的性能应该是最好的。不管用哪个组件，总归是用一个才好。

对于小型的服务器，似乎这几个组件的性能差异并不太明显。我的想法是，既然用了，那就用个最好的吧。但是如果你正在使用别的 opcode cache，比如上面提到的这几个中的一个，从性能提升上讲，倒是没必要立刻就换。

对这个站，首页生成时间：仅使用 PHP 的时候，大约 0.9s；使用 eAccelerator 大约 0.63s；使用 Zend Opcache 后大约 0.55s。测试得非常简陋，多打开几次看看 WP Super Cache 提供的页面生成时间，估计一个平均数。

登录到系统里看了看 Apache 进程的内存占用。之前一个进程不多大一会儿就能占用 40MB 以上的内存，现在基本上没有高于 40MB 的了。只是不知道是 php 5.4 的功劳呢，还是 Zend Opcache 的功劳。

不知道您觉得这个 Zend Opcache 的效果如何？如果您有兴趣，不妨留言写下您的测试结果。

本文来源：水景一页

分类:Linux服务器性能优化, Linux系统架构, PHP编程标签:Opcache

linux下安装opcache扩展

2015年9月2日admin没有评论

linux下安装opcache扩展
http://blog.haohtml.com/archives/14646
参考：http://www.php.net/manual/zh/opcache.installation.php

可以看到 opcache.so 库文件

在PHP.ini添加如下代码

对于上面opcache的各项选项介绍，请参考：http://www.php.net/manual/zh/opcache.configuration.php

重启php，通过 phpinfo(); 命令查看





在phpinfo()信息中, 目前来看有两条信息犹为重要:

Cache hits     (高级缓存命中)

Cache misses  (高级缓存未命中)

在这两条信息中即可观察缓存运行情况, 一目了然

高速缓存带来哪些优化呢? 对代码运行有多大帮助?

我们做个测试, 验证一下什么是opcache.

这是一段非常简单的php代码, 请保存为demo.php文件然后访问, 随意刷新, Cache hits数值会不停地增加, 说明起作用了,

然后你修改代码为:

再刷新demo.php, 应该可以看到效果, 打印出来的值仍然是opcache, 即源码被缓存了, 它不再解析demo.php文件, 试着不停地刷新, 检测多少秒后才更新.

可设置: opcache.force_restart_timeout=180 的时间来控制更新速度.

这就类似于web项目中的静态文件缓存一下, 比如我们加载一个网页, 浏览器会自动帮我们把jpg, css缓存起来, 唯独php没有缓存, 每次均需要open文件, 解析代码,  执行代码这一过程, 而opcache即可解决这个问题, 代码会被高速缓存起来, 提升访问速度.

xampps环境包已经集成此功能, 不过没有开启, 欢迎大家试用.

个人建议: 开发环境非必要情况下不要开启opcache, 服务器上则建议开启,必竟不是天天更新. 缓存起来有它的历史意义.

注意：Zend Opcache 与  eaccelerator 相冲突。要安装 Zend Opcache，可能需要先卸载 eaccelerator —— 如果你用了这个加速模块的话。

配置参数详解

opcache.enable(默认值:1)

Zend Optimizer + 的开关, 关闭时代码不再优化.

opcache.memory_consumption(默认值:64)

Zend Optimizer + 共享内存的大小, 总共能够存储多少预编译的 PHP 代码(单位:MB).

opcache.interned_strings_buffer(默认值:4)

Zend Optimizer + 中interned字符串的占内存总量.(单位:MB)

opcache.max_accelerated_files(默认值:2000)

Zend Optimizer + 哈希表中键数量的最大值(一个脚本文件应当是对应一个key的,所以应当就是允许缓存的文件最大数量).这个值实际上是素数列表{ 223, 463, 983, 1979, 3907, 7963, 16229, 32531, 65407, 130987 }中第一个大于设定值的数字.值设定范围: 200 – 100000

opcache.max_wasted_percentage(默认值:5)

“浪费”的内存达到此值对应的百分比,就会发起一个重启调度.

opcache.use_cwd(默认值:1)

开启这条指令, Zend Optimizer + 会自动将当前工作目录的名字追加到脚本键上, 以此消除同名文件间的键值命名冲突.关闭这条指令会提升性能,但是会对已存在的应用造成破坏.

opcache.validate_timestamps(默认值:1)

禁用时, 您必须手动重置Zend Optimizer +或重新启动Web服务器,以使文件系统的更改生效. 检查的频率是由指令 “opcache.revalidate_freq” 控制.

opcache.revalidate_freq(默认值:2)

多久(以秒为单位)检查文件时间戳以改变共享内存的分配.”1″ 表示一秒校验一次, 但是是每个请求一次. “0″ 表示总是在校验.

opcache.revalidate_path(默认值:0)

允许或禁止在 include_path 中进行文件搜索的优化. 如果文件搜索被禁用而且可以在相同的 include_path 中找到这个缓存的文件, 文件搜索就不会再进行下去了. 因此,如果 include_path 其它地方有一个同名文件的话, 那就找不到了. 如果这个优化对您的应用有影响,那么应当允许它搜索. 默认情况下,指令是禁止的,这就意味着,优化是处于激活状态的.

opcache.save_comments(默认值:1)

如果禁用,所有的文档注释都从代码中剔除以此减少优化过的代码的大小.禁用 “文档注释” 可能会破坏一些现有的应用和框架(例如: Doctrine, ZF2, PHPUnit).

opcache.load_comments(默认值:1)

如果禁用, PHP文档注释将不会从 SHM(共享内存) 中读取. 尽管”文档注释”还是会被存储(save_comments=1), 但是那些无论如何都用不上的注释就不必被应用读取了.

opcache.fast_shutdown(默认值:0)

如果开启, 一个快速关闭队列用以提速代码. 快速关闭队列并不释放每个已分配的块, 而是让 Zend 引擎内存管理器来干这个活.

opcache.enable_file_override(默认值:0)

允许覆盖文件存在（file_exists等）的优化特性。

opcache.optimization_level(默认值:0xffffffff)

一个位掩码,其中每个位允许或禁用相应的缓存通过.

opcache.inherited_hack(默认值:1)

启用此Hack可以暂时性的解决”can’t redeclare class”错误. Zend Optimizer + 存储着 DECLARE_CLASS 操作码使用继承的地方(这些是唯一可以被PHP执行的操作码,但是也可能因为优化引起的父类找不到而无法执行).当文件被读取时, Optimizer 会试着通过当前环境绑定被继承的类. 这样做的问题是. DECLARE_CLASS 的操作码可能不被当前脚本所需要, 如果脚本需要操作码至少完成类的定义操作, 那么它就会无法执行.这指令的默认是禁用的, 这就表示优化是有效的.
该在 php 5.3 以及以上的版中不再被需要, 而且这个设置也不会生效.

opcache.dups_fix(默认值:0)

启用此Hack可以暂时性的解决”can’t redeclare class”错误.

opcache.blacklist_filename(默认值:无)

Zend Optimizer + 黑名单文件的位置.

Zend Optimizer + 黑名单是一个文本文件包含了那些不能被加速的文件名.文件格式为每行一个文件名.文件名须为一个完整的路径或者紧紧一个文件前缀(如:/var/www/x 屏蔽了 /var/www 文件和目录中所有以 ‘x’ 开始的文件或者目录). 需要屏蔽的文件通常符合下面三个原因中的一个:

1) 目录包含了自动生成的代码, 如 Smarty 或者 ZFW 的缓存.

2) 执行加速时代码无法很好的运行, 从而耽误了编译时评估.

3) 代码触发了一个 Zend Optimizer + 的 Bug

opcache.max_file_size(默认值:0)

通过文件大小屏除大文件的缓存.默认情况下所有的文件都会被缓存.

opcache.consistency_checks(默认值:0)

每 N 次请求检查一次缓存校验.默认值0表示检查被禁用了.由于计算校验值有损性能,这个指令应当紧紧在开发调试的时候开启.

opcache.force_restart_timeout(默认值:180)

从缓存不被访问后,等待多久后(单位为秒)调度重启.Zend Optimizer + 依托此指令来确定一个进程可能在处理过程中出现问题的情况.这段时间(等待时间)过后, 假设 Zend Optimizer + 发生了一些问题, 并开始干掉那些仍然持有预防重启锁的进程.当这些发生时, 如果日志的级别是3级或以上, 一个 “killed locker” 的错误就会被记录到 Apache 的日志中.

opcache.error_log(默认值:无)

Zend Optimizer + 的错误日志文件名.留空表示使用标准错误输出(stderr).

opcache.log_verbosity_level(默认值:1)

将错误信息都导向 Web 服务器日志.默认的只有致命错误(level 0) 或者错误(level 1)才会被记录.你也可以允许警告(level 2),提示消息(level 3) 或者 调试消息(level 4)被记录下来.

opcache.preferred_memory_model(默认值:无)

内存共享的首选后台.留空则是让系统选择.

opcache.protect_memory(默认值:0)

防止共享内存在脚本执行期间被意外写入, 仅用于内部调试.

opcache.mmap_base(默认值:无)

共享内存段映射基础(仅适用于Windows).所有的PHP进程必须映射到相同的共享内存地址空间.该指令用于手动修复 “Unable to reattach to base address” 错误.