Zend Opcache で PHP を高速化する (2)

Optimizer+ は、クローズドソースですが、Zend によって開発された無料で使用できる PHP 最適化アクセラレーション コンポーネントです。これは、最初で最速のオペコード キャッシュ ツールです。現在、Zend Technologies は、PHP ライセンスに基づいて Optimizer+ を Zend Opcache としてオープンソース化しています。

Zend OPcache は、オペコードのキャッシュと最適化を通じて、より高速な PHP 実行を提供します。プリコンパイルされたスクリプト ファイルは後で使用できるように共有メモリに保存されるため、ディスクからコードを読み取ってコンパイルする時間の消費が回避されます。同時に、コードの実行を高速化するためにいくつかのコード最適化モードも適用します。

1. オペコードキャッシュとは何ですか?

インタプリタはスクリプト コードの分析を完了すると、オペレーション コード (Operate Code、opcode) とも呼ばれる、直接実行できる中間コードを生成します。オペコード キャッシュの目的は、コンパイルの繰り返しを回避し、CPU とメモリのオーバーヘッドを削減することです。動的コンテンツのパフォーマンスのボトルネックが CPU やメモリではなく、データベース クエリによって引き起こされるディスク I/O オーバーヘッドなどの I/O 操作にある場合、オペコード キャッシュのパフォーマンス向上は非常に限られます。しかし、オペコード キャッシュは CPU とメモリのオーバーヘッドを削減できるので、これは常に良いことです。環境に優しい態度では、消費量は可能な限り削減されるべきですよね? :D

最新のオペコード キャッシュ (Optimizer+、APC2.0+、その他) はストレージに共有メモリを使用し、実行前にコードを「逆シリアル化」することなく、そこからファイルを直接実行できます。これにより、パフォーマンスが大幅に向上し、多くの場合、サーバー全体のメモリ消費量が減少し、欠点はほとんどありません。

2. Optimizer+ と APC の長所と短所の比較

Optimizer+ は 2013 年 3 月中旬に Opcache に名前変更されました。

PHP wiki の議論によると、Zend Opcache は php 5.5 に統合されようとしています。 APC の競合相手として、新しい Zend Opcache が APC の地位に代わる可能性がありますが、OptimizerPlus には APC のようなユーザー キャッシュ機能はありません。

APC に対する OPTIMIZER+ の利点

パフォーマンス。テストによると、Zend Optimizer+ は一貫して APC を上回るパフォーマンスを示しています。コードに応じて、1 秒あたりに処理されるリクエストの数は 5 ～ 20% 増加します。 Google ドキュメントに記録されたテスト結果のうち、WordPress 2.1.1 (新しいバージョンの WP でテストしなかった理由はわかりません) のパフォーマンスは約 8% 向上しました。理論的には、WP 3.5.1 ではパフォーマンスが約 5 ～ 10% 向上するはずです。 WordPress を実行しているサーバーの場合、Optimizer+ を使用すると、CPU 使用率が大幅に削減され、ページの読み込み速度が向上します (グラフィックはこちら)。 新しい PHP バージョンをサポートします。 Zend と PHP コミュニティは、Optimizer+ が最新バージョンの PHP をサポートするのを支援します。 信頼性。 Optimizer+ には、データ破損によるサーバーのクラッシュを防ぐオプションの破損検出機能があります。 互換性の向上。 PHP コミュニティは、Optimizer+ がコミュニティでサポートされているすべてのバージョンの PHP と互換性を持つことを目指しています。

OPTIMIZER+ に対する APC の利点

APC にはデータ キャッシュ API がありますが、Optimizer+ にはありません。 APC は、古い無効なスクリプトによって占有されていたメモリを再利用できます。 APC には、使用されなくなったスクリプトに関連付けられたメモリを再利用できるメモリ マネージャーがあります。 Optimizer+ は異なり、そのようなメモリを「ダーティ」としてマークしますが、再利用はしません。 Optimizer+ は、「ダーティ」メモリ使用量の一定の割合が設定されたしきい値に達すると、自動的に再起動します。この動作には、安定性の点で長所と短所の両方があります。

3. Zend Opcode を使用する

これで、PHP 最適化加速ツールとして APC の代わりに Zend Opcache を使用できるようになりました。現在の Zend オペコードは、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 のクイック インストール セクションの冒頭で使用されます

$PHP_DIR/bin/phpize

phpize へのパスがわからない場合は、対応する推奨最適化設定も README ファイルに記載されています。

EPEL ソースからインストールして構成する

ソース コードからインストール プログラムをコンパイルするのは好きではありません。1 つはスキルが限られているため、もう 1 つはトラブルが怖いためです。以下では、CentOS での操作を例に、EPEL インストール ソースから Zend Opcache をインストールする方法を、私の VPS の構成に基づいて説明します。

EPEL コミュニティは Zend Opcache インストール パッケージを提供しており、yum で直接インストールできます。もちろん、EPEL インストール ソースが構成され、使用されていることが前提となります。そうでない場合は、ここを参照してください。

念のため、REMI インストール ソースの PHP はすでにバージョン 5.4 です。一部の人々は、WordPress のパフォーマンスが PHP 5.3 よりも PHP 5.4 の方が優れている (10% 高速で RAM 消費量が少ない) ことをテストしているため、PHP をアップグレードすることは悪いことではありません。

操作手順:

配置使用 epel 安装源。已有则跳过。 删除 eaccelerator、xcache、apc：

yum remove php-eaccelerator php-xcache php-apcu

没有使用则跳过。

对系统执行升级：

yum update

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

Updating   : php-common-5.4.14-1.el6.remi.i686                                                         1/26WARNING : These php-* RPM are not official Fedora / Red Hat build andoverrides the official ones. Don't file bugs on Fedora Project nor Red Hat.Use dedicated forums created as /etc/php.ini.rpmnew  Updating   : mysql-libs-5.5.31-1.el6.remi.i686                                                         2/26WARNING : This MySQL RPM is not an official Fedora / Red Hat build and itoverrides the official one. Don't file bugs on Fedora Project nor Red Hat.Use dedicated forums

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

安装 Zend Opcache（pecl 版本）：

yum install php-pecl-zendopcache

安装时产生的 opcache 的配置文件位于默认的 /etc/php.d 目录中：

opcache-default.blacklistopcache.ini

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

vi /etc/php.d/opcache.ini

对照如下推荐配置修改并保存即可（可参考完整的 Zend Opcache 配置信息）：

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

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

service httpd restart

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

php -v

输出结果类似于：

PHP 5.4.14 (cli) (built: Apr 11 2013 11:04:35)Copyright (c) 1997-2013 The PHP GroupZend 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 的效果如何？如果您有兴趣，不妨留言写下您的测试结果。©