opcache PHP新的字節碼緩存擴展
字節碼緩存組件 Zend Optimizer+ 現在更改名字為 Zend opcache了。且在php 5.5版本后，會集成到php的官方組件中，也就沒有必要安裝其他的APC,eAccelerator等了。。
APC與Opcache都是字節碼緩存也就是，PHP在被編譯的時候，首先會把php代碼轉換為字節碼，字節碼然后被執行。
php文件第二次執行時，同樣還是會重新轉換為字節碼，但是很多時候，文件內容幾乎是一樣的，比如靜態HTML文件，生成后內容許久都不會改變，用戶訪問請求直接由服務器讀取響應給客戶端瀏覽器。都不用經過PHP進行解析構建了。
內存中的字節碼數據，可以直接緩存進行二次編譯。這樣程序就會快一些，cpu的消耗也少了。
詳細介紹看這兩篇
新一代 PHP 加速插件 Zend Opcache
php的 zend opcache VS apc 性能比較
我主要是用來測試了一下phpcmsV9.5.4 的默認index.php主頁，沒有數據內容，但有sql查詢操作
測試是Apache2.2.6 32Bit 服務器，PHP 5.4.26 ts，mysql 5.6.16 64Bit
ab 版本 This is ApacheBench, Version 2.3 <$Revision: 655654 $>
請求數：1000
並發數：10
沒有加載opcache測試
第一次測試
吞吐率 38.46 rps，耗時26.001 s，每個請求耗時260.015 ms
第二次測試
吞吐率有所提高 40.73 rps，耗時 24.554 s，每個請求耗時245.544 ms
加載opcache進行測試
opcache版本 php_opcache-7.0.3-5.4-ts-vc9-x86
opcache配置信息
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
第一次配置opcache好后 cache 狀態
cache hits 命中數 1
cache misses 未命中數 1
使用內存225.2Kb
opcache第一次測試
吞吐率提升到49.11rps，總耗時20.361 s，每個請求耗時下降到203.612 ms
在phpinfo中可查看opcache的命中數量情況
命中數量已達到43957，內存使用2.31Mb。
opcache第二次測試
吞吐率提升到47.87rps，總耗時20.888 s，每個請求耗時下降到208.882 ms
opcache之后的兩次壓測數據變化不大，每個請求耗時在1ms差距內，吞吐率也在1~2 rps
但與之前未啟用opcache時，總耗時少了4 ~ 6 s，每個請求耗時少了40 ~ 60 ms。吞吐率也提升了 8%。
這都是在一行代碼未改的情況下有效性能提升。
php文件被編譯為字節碼進行內存緩存，如果在生成環境中，代碼和內容變量都是比較固定的
緩存起來的內容就可以高速的返回，用戶會得到較快的響應。
但是在本地開發是，建議不要開啟opcache，否則就得不到最新的值
例如：
<?php header('Content-type:text/html; charset=utf-8'); $str = 'abc'; echo $str; // 輸出abc ?>
賦予$str 一個新的值
<?php header('Content-type:text/html; charset=utf-8'); $str = 'new abc'; echo $str; // 輸出的還是 abc ?>
這是因為$str 已經被編譯為字節碼了，再次訪問時，內存里面還是可以找到對應的緩存，就沒有進行重新編譯，返回的值也就還是之前的值 abc
不過，opcache有一個參數可以用來設置緩存時間長度
默認時間為180秒，還是建議本地不用開啟opcache
opcache.force_restart_timeout (default "180")
注意：官方給了一個Note，如果opcache要與xdebug同時加載，那么opcache需要在xdebug之前進行加載。
但是我本地測試了一下，xdebug先加載，再加載opcache，也正常啟動了，xdebug，opcache都加載成功，opcache緩存也正常。
不過還是按照官方的建議來安裝加載，否則可能會出現奇怪的錯誤吧。
轉載自天空的顏色