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 和記憶體開銷的降低，這總歸是好事 —— 本著環保的態度，也應該盡量減少消耗不是？ :D
現代操作碼快取器（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 中快速安裝一節的開頭就用到，
$PHP_DIR/bin/phpize
如果不清楚 phpize 的路徑，可以，
whereis phpize
README 文件中也有相應的優化設定。
從 EPEL 來源安裝並配置
我不喜歡從原始碼編譯安裝程序，一個是水平有限，一個就是怕麻煩。以下介紹從 EPEL 安裝來源安裝 Zend Opcache，以 CentOS 上的操作為例，基於我的 VPS 的設定。
EPEL 社區已經提供了 Zend Opcache 的安裝包，可以直接 yum 安裝。當然，前提是已經設定使用了 EPEL 的安裝來源。如果沒有，可以參考這裡。
提醒一下，REMI 安裝來源上的 PHP 已經是 5.4 版本了。鑑於有人測試說 WordPress 在 PHP 5.4 上的表現要優於在 PHP 5.3 上的表現（10% faster and lower ram consuming），所以順便升級 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/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 /etc/php。 /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 尋求幫助了。呵呵，貌似出問題都是在網路上找，還真是很少到官方論壇問問題。像我這樣的入門用戶，也不會遇到那麼深度的問題。
安裝Zend Opcache（pecl 版本）：
yum install php-pecl-zendopcache
安裝時產生的opcache 的設定檔位於預設的 /etc/php.d 目錄中：list中產生的opcache 的設定檔位於預設的 /etc/php.d 目錄中：list opcache.ini
這個設定檔採用的基本就是README 中的建議設置，只有幾個地方需要修改。
對照如下建議配置修改並儲存即可（可參考完整的Zend Opcache 設定資訊）：
opcache.revalidate_freq=60
opcache.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 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
以上就是使用ZendOpcache加速PHP的內容，更多相關文章請關注PHPcn網（www.php.cn）！
