PHP中我們了解了那么多關于php7的知識,不知道你們對php7有多少了解,我相信很大一部分人會不知道這部分知識點,那么不急本篇文章就是帶領大家更深刻的去了解這個內容。
研究PHP7技術的背景
- 公司開源節(jié)流的大背景下 我們需要節(jié)省成本
- PHP7相對于現(xiàn)在魅族線上的PHP版本5.X 性能提升至少一倍以上
- 社區(qū)日活用戶增長迅速(15年數(shù)據(jù) 日均PV 年增長348% 日均UV年增長112%)
- 移動互聯(lián)網的大環(huán)境下 要求我們的程序能夠更快的速度響應用戶的請求 以滿足更好的用戶體驗
- 對新技術的求知欲望(滿足自己的一點點虛榮心)
PHP7性能小記
PHP7性能初印象(比PHP5提升3倍+)
1. 性能對比 – 快速排序算法(隨機生成5000個數(shù)后按照快速算法排序)
PHP5.1 5000個數(shù)快速排序平均響應時間2587ms
PHP5.2 5000個數(shù)快速排序平均響應時間2625ms
PHP5.3 5000個數(shù)快速排序平均響應時間2509ms
PHP5.4 5000個數(shù)快速排序平均響應時間2339ms
PHP7.0 5000個數(shù)快速排序平均響應時間685ms
2.性能對比 – WordPress首頁
PHP5.1 WordPress平均響應時間505ms
PHP5.2 WordPress平均響應時間521ms
PHP5.3 WordPress平均響應時間498ms
PHP5.4 WordPress平均響應時間470ms
PHP7.0 WordPress平均響應時間158ms
3.性能對比 – Flyme社區(qū)APP
PHP5.4 500個數(shù)快速排序TPS 552
PHP7.0 500個數(shù)快速排序TPS 3165
Flyme社區(qū)APP首頁 PHP5.4 TPS 1535
Flyme社區(qū)APP首頁 PHP7.0 TPS 1975
Flyme社區(qū)APP板塊列表頁 PHP5.4 TPS 2237
Flyme社區(qū)APP板塊列表頁 PHP7.0 TPS 2387
性能測試遇到的幾個問題&解決辦法
為什么PHP7的性能可以提高這么多?
1. JIT
2. Zval的改變
3. 內部類型zend_string
4. PHP數(shù)組的變化(HashTable和Zend Array)
5. 函數(shù)調用機制(Function Calling Convention)
6. 通過宏定義和內聯(lián)函數(shù)(inline),讓編譯器提前完成部分工作
為什么PHP7的在實際的業(yè)務性能提高才30%左右?
- 實際的業(yè)務不一定有很復雜的計算邏輯
- 實際的業(yè)務會用到Redis 和MYSQL,網絡和IO的瓶頸 影響了PHP7的整體性能
- HTTPS的性能問題 限制了PHP7的能力
Redis Proxy的問題
Redis Proxy目的是為了做Redis高可用&分布式緩存用的
經過性能測試,相對直接連接redis而已,用Proxy的性能損耗在10-15%左右(不同的業(yè)務 可能影響有比較大的差異)
那么Proxy是不是還有優(yōu)化的空間的呢?
PHP和Redis長短鏈接的問題
PHP7 Redis長連接比短連接性能高10%左右(不同的業(yè)務差別比較大)
MYSQL數(shù)據(jù)庫連接池的問題
數(shù)據(jù)庫連接池負責分配、管理和釋放數(shù)據(jù)庫連接,它允許應用程序重復使用一個現(xiàn)有的數(shù)據(jù)庫連接,而不是再重新建立一個。
Atlas 是360開發(fā)和維護的數(shù)據(jù)庫中間件。是一個位于應用程序與MySQL之間,它實現(xiàn)了MySQL的客戶端與服務端協(xié)議,作為服務端與應用程序通訊,同時作為客戶端與MySQL通訊。它對應用程序屏蔽了DB的細節(jié),同時為了降低MySQL負擔。
Atlas 支持主庫宕機不影響讀、讀寫分離、自動分表、安全處理、平滑重啟、連接池等
用了數(shù)據(jù)庫連接池后 TPS性能杠杠的 整整提高了80%
來看看效果吧
PHP7性能優(yōu)化的幾個細節(jié)
PHP7 Opcache(提升1倍左右)
Opcache的工作原理 ?
- PHP是解釋型語言,Zend引擎會將PHP代碼解釋為可執(zhí)行機器碼(Operate Code)之后再交由CPU執(zhí)行。
-
Opcache是如何加速的
-
看看加了opcache后的成果吧(請求平均響應時間足足減少了一倍 有木有)
編譯器GCC4.8+PGO(提升5%-10%)
PGO是一項編譯優(yōu)化技術,它可以配合GCC等編譯器使用,提高編譯器的編譯效率。
雖然PGO可以提高編譯效率,但它并沒有被廣泛使用。
原因很簡單:
1. 它繁雜的雙編譯模型 和 有限的使用場景,讓PGO顯得很雞肋
2. 在有了opcache這樣的產品出現(xiàn)后,PGO帶來的性能提升并不是很明顯。
開啟多個PHP-FPM主進程(提高10%左右)
<source lang="xml" collapse="false" first-line="1"> #php-fpm.conf listen = /dev/shm/php-fcgi.sock #php-fpm2.conf listen = /dev/shm/php-fcgi2.sock #/usr/local/php/sbin/php-fpm --fpm-config /usr/local/php/etc/php-fpm.conf #/usr/local/php/sbin/php-fpm --fpm-config /usr/local/php/etc/php-fpm2.conf #代理 upstream backend{ server unix:/dev/shm/php-fcgi.sock; server unix:/dev/shm/php-fcgi2.sock; } </source>
HugePage(提升2%-3%)
默認的內存是以4KB分頁的,而虛擬地址和內存地址是需要轉換的, 而這個轉換是要查表的,
CPU為了加速這個查表過程都會內建TLB(Translation Lookaside Buffer), 顯而易見如果虛擬頁越小,表里的條目數(shù)也就越多,
而TLB大小是有限的,條目數(shù)越多TLB的Cache Miss也就會越高, 所以如果我們能啟用大內存頁就能間接降低這個TLB Cache Miss。
<source lang="xml" collapse="false" first-line="1"> opcache.huge_code_pages=1 sudo sysctl vm.nr_hugepages=128 </source>
相性能參數(shù)優(yōu)化
PHP部分性能參數(shù)優(yōu)化
-
php.ini配置
<source lang="xml" collapse="false" first-line="1"> opcache.enable=1 opcache.enable_cli=1 opcache.memory_consumption=128 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=4000 opcache.revalidate_freq=60 opcache.save_comments=0 opcache.fast_shutdown=1 opcache.huge_code_pages=1 opcache.file_cache=/dev/shm/opcache/ </source>
-
PHP-FPM
<source lang="xml" collapse="false" first-line="1"> listen = /dev/shm/php-fcgi.sock pm = static pm.max_children = 320 pm.max_requests = 10240 </source>
未解決的問題
Nginx HTTPS的性能問題
研究PHP7技術的背景
- 公司開源節(jié)流的大背景下 我們需要節(jié)省成本
- PHP7相對于現(xiàn)在魅族線上的PHP版本5.X 性能提升至少一倍以上
- 社區(qū)日活用戶增長迅速(15年數(shù)據(jù) 日均PV 年增長348% 日均UV年增長112%)
- 移動互聯(lián)網的大環(huán)境下 要求我們的程序能夠更快的速度響應用戶的請求 以滿足更好的用戶體驗
- 對新技術的求知欲望(滿足自己的一點點虛榮心)
相關學習視頻分享:php視頻教程