讓子彈飛~利用OPcache擴展提升PHP7性能 | laravel篇

前言 十一點半了,沉澱時間到了。

PHP在運行的時候,存在這樣的一個流程,先將PHP代碼預編譯,生成字節碼後再加載到內存裏,最後CPU在內存上執行編譯後的字節碼片段。我們會發現,在執行PHP程序的時候,每次都經過這樣的流程,此非浪費Time,是的,很容易聯想到:爲何不向C++語言看齊呢,將源碼編譯成可直接加載到內存so哥呢?呃呃?。快拿出你的步槍,裝上這顆子彈OPcache。自從PHP5.5.0出來後,就內置此zend擴展了。


What is OPcache OPcache是PHP中的Zend擴展,可以大大提升PHP的性能。 OPcache 通過將 PHP 腳本預編譯的字節碼存儲到共享內存中來提升 PHP 的性能, 存儲預編譯字節碼的好處就是 省去了每次加載和解析 PHP 腳本的開銷。


Judge whether it has been extended OPcache

➜  ~ php -m | grep OPcache
Zend OPcache
Zend OPcache

倘若沒有開啓的話,可以在php.ini配置中開啓 /home/samego/service/php7.2/php.ini

➜  ~ echo zend_extension="opcache.so" >> /home/samego/service/php7.2/php.ini

About OPcache configure 接下來,我們需要在 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

你可以使用這些配置值進行實驗,具體配置值取決於你的應用大小和服務器配置。 學習於Laravel社區


Laravel OPcache

  • install
➜  ~ composer require appstract/laravel-opcache
  • configure
➜  ~ php artisan vendor:publish --provider="Appstract\Opcache\OpcacheServiceProvider" --tag="config"
  • command
# Clear OPcache:
➜  ~ php artisan opcache:clear

# Show OPcache config:
➜  ~ php artisan opcache:config

# Show OPcache status:
➜  ~ php artisan opcache:status

# Pre-compile your application code:
➜  ~ php artisan opcache:optimize

拭目以待的場景測試

個人比較喜歡數據說話 場景:(1)請求GET接口 (2)測試次數10 (3)併發數爲100

case non-extension

1000個請求,花費32.32秒,每秒30.94個請求

Transactions:               1000 hits
Availability:             100.00 %
Elapsed time:              32.32 secs
Data transferred:           0.97 MB
Response time:              0.32 secs
Transaction rate:          30.94 trans/sec
Throughput:             0.03 MB/sec
Concurrency:                9.96
Successful transactions:        1000
Failed transactions:               0
Longest transaction:            0.44
Shortest transaction:           0.11

case had extend

1000個請求,花費2.94秒,每秒340.14個請求

Transactions:               1000 hits
Availability:             100.00 %
Elapsed time:               2.94 secs
Data transferred:           0.97 MB
Response time:              0.03 secs
Transaction rate:         340.14 trans/sec
Throughput:             0.33 MB/sec
Concurrency:                9.86
Successful transactions:        1000
Failed transactions:               0
Longest transaction:            0.29
Shortest transaction:           0.01

看到這組數據,我甚是高興,無比的喜悅。在性能方面,形成如此鮮明的對比,我二話不說~OPcache is right (¦3[▓▓] 晚安 價值源於技術,技術源於分享!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章