每一次執行 PHP 腳本的時候,該腳本都須要被編譯成字節碼,而 OPcache 能夠對該字節碼進行緩存,這樣,下次請求同一個腳本的時候,該腳本就不須要從新編譯,這極大節省了腳本的執行時間,從而讓應用運行速度更快,同時也節省了服務器的開銷。php
咱們固然很想知道到底進行了怎樣的優化,儘管性能提高高度依賴於應用和服務器的配置,不過咱們能夠經過運行基準測試(benchmark)有一個大概的瞭解。laravel
爲此我專門準備了一個很低配置的機器:1核CPU,1G內存來運行 Apache 基準測試。我請求的是 Laravel 5.4 默認的歡迎頁面,讓 10 個併發請求持續訪問 1 分鐘,如下是關閉 OPcache 的基準測試結果:git
OPcache disabled: 10.18 requests per second
對於一個這麼低配置的服務器而言,這也不算太壞,可是咱們能夠作得更好。開啓 OPcache 的基準測試結果以下(使用默認 OPcache 配置):github
Enabled with default values: 34.52 requests per second
差距仍是很大的!咱們接下來對 OPcache 配置進行優化,基準測試的表現效果更好:緩存
Enabled with optimized values: 42.53 requests per second
這把服了沒有?服務器
首先,咱們須要確保在服務器上安裝了 OPcache,從 PHP 5.5 開始,OPcache 已經成爲 PHP 核心的一部分,因此對於 Laravel 開發者而言,基本上不須要手動去安裝這個擴展。併發
固然,若是不放心,能夠經過查看 phpinfo()
進行確認:app
<?php phpinfo();
該腳本會顯示全部 PHP 安裝的擴展。在頁面搜索 「OPcache」,若是找到,證實已經安裝。若是沒有,則須要本身去安裝。工具
接下來,咱們須要在 PHP 的配置文件中啓用 OPcache(默認是關閉的):性能
opcache.enable=1
下面咱們繼續對 OPcache 進行一些優化配置:
opcache.memory_consumption=512
這個配置表示你想要分配給 OPcache 的內存空間(單位:MB),設置一個大於 64 的值便可。
opcache.interned_strings_buffer=64
這個配置表示你想要分配給實際字符串的空間(單位:MB),設置一個大於 16 的值便可。
opcache.max_accelerated_files=32531
這個配置表示能夠緩存多少個腳本,將這個值儘量設置爲與項目包含的腳本數接近(或更大)。
opcache.validate_timestamps=0
改配置值用於從新驗證腳本,若是設置爲 0(性能最佳),須要手動在每次 PHP 代碼更改後手動清除 OPcache。若是你不想要手動清除,能夠將其設置爲 1 並經過 opcache.revalidate_freq
配置從新驗證間隔,這可能會消耗一些性能,由於須要每隔 x 秒檢查更改。
opcache.save_comments=1
這個配置會在腳本中保留註釋,我推薦開啓該選項,由於一些庫依賴於這個配置,而且我也找不出什麼關閉它的好處。
opcache.fast_shutdown=0
快速關閉會給一個更快速清理內存的機制,不過,在個人基準測試中,更慢一些,可能這會應用帶來一些性能提高,可是你須要本身去嘗試。
因此,最終的配置優化長這樣:
opcache.enable=1 opcache.memory_consumption=512 opcache.interned_strings_buffer=64 opcache.max_accelerated_files=32531 opcache.validate_timestamps=0 opcache.save_comments=1 opcache.fast_shutdown=0
你可使用這些配置值進行實驗,具體配置值取決於你的應用大小和服務器配置。
最後,保存這個配置文件並重啓 Web 服務器,你的應用確定會變得更快。
前面提到,opcache.validate_timestamps
設置爲 0
的話咱們須要在每次修改 PHP 代碼後手動清除 OPcache。爲此我建立了一個擴展包來提供相應的 Artisan 命令處理 OPcache 清理事宜:https://github.com/appstract/laravel-opcache。
安裝完擴展後,只需執行以下命令便可清理 OPcache:
php artisan opcache:clear
此外,改擴展包還提供了一些其餘有用的工具,你能夠在項目的 GitHub頁面 上看到。