找到的较好的资料,转载自以下网站,里面有较多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下安装opcache扩展
linux下安装opcache扩展
http://blog.haohtml.com/archives/14646
参考:http://www.php.net/manual/zh/opcache.installation.php
1
2
3
4
5
6
7
|
wget http:
//pecl
.php.net
/get/zendopcache-7
.0.2.tgz
tar
zxvf zendopcache-7.0.2.tgz
cd
zendopcache-7.0.2
/usr/local/php/bin/phpize
.
/configure
--with-php-config=
/usr/local/php/bin/php-config
make
&&
make
install
ls
/usr/local/php/lib/php/extensions/no-debug-non-zts-20090626/
|
可以看到 opcache.so 库文件
在PHP.ini添加如下代码
1
2
3
4
5
6
7
8
9
|
[Zend Opcache]
zend_extension = /usr/local/php/lib/php/extensions/no-debug-non-zts-
20090626
/opcache.so
opcache.memory_consumption=
64
opcache.interned_strings_buffer=
8
opcache.max_accelerated_files=
4000
opcache.force_restart_timeout=
180
opcache.revalidate_freq=
60
opcache.fast_shutdown=
1
opcache.enable_cli=
1
|
对于上面opcache的各项选项介绍,请参考:http://www.php.net/manual/zh/opcache.configuration.php
重启php,通过 phpinfo(); 命令查看
在phpinfo()信息中, 目前来看有两条信息犹为重要:
Cache hits (高级缓存命中)
Cache misses (高级缓存未命中)
在这两条信息中即可观察缓存运行情况, 一目了然
高速缓存带来哪些优化呢? 对代码运行有多大帮助?
我们做个测试, 验证一下什么是opcache.
1
2
3
|
<?php
echo
'opcache'
;
?>
|
这是一段非常简单的php代码, 请保存为demo.php文件然后访问, 随意刷新, Cache hits数值会不停地增加, 说明起作用了,
然后你修改代码为:
1
2
3
|
<?php
echo
'cache new'
;
?>
|
再刷新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” 错误.