本月php7.0釋出，網上關于新版的介紹很多，介于7.0在正式釋出之前已經發過若幹個beta、8個RC，應該不會出現重大問題。今日我将一台機器更新至php7.0并将有關資訊記錄如下。
本人使用 ubuntu 12.04 LTS，在網上已經找到7.0正式版的ppa，是以不需要編譯，使用如下指令可直接安裝。
安裝PHP7.0與擴充
sudo add-apt-repository ppa:ondrej/php-7.0
sudo apt-get update
sudo apt-get install php7.0-fpm php7.0-cli php7.0-common php7.0-json php7.0-mysql php7.0-opcache php7.0-curl 由于memcached、redis擴充并沒有在pecl釋出支援php7的最新版本，是以需要到github找到php7的分支進行手動編譯安裝。
redis、memcached的github位址如下
https://github.com/phpredis/phpredis/5
https://github.com/rlerdorf/php-memcached4
redis 安裝方法
git clone https://github.com/phpredis/phpredis/
cd phpredis
git checkout php7
phpize
./configure
make
ssudo make install memcached 安裝方法
memcached 需要先下載下傳libmemecached 庫才能正常編譯。
wget https://launchpad.net/libmemcached/1.0/1.0.18/+download/libmemcached-1.0.18.tar.gz
tar -zxvf libmemcached-1.0.18.tar.gz
cd libmemcached-1.0.18
./configure
make
sudo make install
sudo apt-get install pkg-config
git clone https://github.com/rlerdorf/php-memcached.git
cd php-memcached
git checkout php7
phpize
./configure
make
sudo make install 自己編譯的這2個擴充需要手動在配置檔案裡加載
sudo touch /etc/php/mods-available/redis.ini
sudo touch /etc/php/mods-available/memcached.ini
#并将兩個檔案内容寫上 extension=redis.so
#extension=memcached.so
cd /etc/php/7.0/fpm/conf.d
sudo ln -s /etc/php/mods-available/redis.ini ./
sudo ln -s /etc/php/mods-available/memcached.ini ./
如果指令行下需要啟用擴充，同樣需要在cli/conf.d 目錄下将其連結過去。 最後重新開機伺服器 sudo service php7.0-fpm restart
配置檔案的調整
由于php7.0最大的改進是性能，是以務必要啟用opcache 保證其能發揮最大作用。
#将php.ini 的如下配置啟用。
opcache.enable=1
opcache.enable_cli=1
opcache.file_cache=/tmp
opcache.error_log=/var/log/opcache_errors.log
#ppa安裝的包預設error_display 是off的。 而且error_log 是注釋的，意味着出現問題時檢視不到任何資訊。
#是以請寫入如下配置 error_log=/var/log/php_errors.log
sudo chown www-data.www-data /var/log/php_errors.log #本人安裝的是nginx伺服器，請確定使用者數組更改為與自己webserver一樣的，否則還是不會出現任何提示。opcache_errors.log檔案同樣如此。 關于opcache的更多内容可以通路這裡檢視 http://www.laruence.com/2015/12/04/3086.html9
異常處理與解決
在配置完成後，就需要實際的将程式跑一下了。目前将老系統轉移到php7.0後，第一個錯誤就是
09-Dec-2015 12:27:48 Asia/Chongqing] PHP Fatal error: Uncaught Error: Call to undefined function set_magic_quotes_runtime() in /init.php:46
已經不再存在set_magic_quotes_runtime 這個函數了。如果要相容的話需要加上判斷
if(PHP_VERSION_ID < 70000){
set_magic_quotes_runtime();
} 監控與調優
我在系統裡安裝了OneAPM提供的Agent。這樣可以實時監測到整個系統的運作情況。其他版本的Agent官方網站已經提供了下載下傳。截止本文落筆，php7.0版本官方提供了一個下載下傳位址是；8https://oneapm.kf5.com/p_w_uploads/download/366552/0015667f0036f47c827fcb8fcbfbc79/8
在這之前更多人會使用xhprof來檢測和優化系統，但是xhprof對整體的程式性能采集樣本無法很好的歸納，也沒有很好的可視化曲線圖和web事務跟蹤，導緻在短時間内很難對系統瓶頸進行評估。
是以我使用OneAPM的phpAget來完成這些工作，OneAPM同樣使用定時采樣定時彙報的方式來收集性能資訊，并且官方宣稱耗費資源小于5%。不過對于使用性能提升數倍的php7.0來部署的話這些損耗可以忽略不計，而且本人隻在叢集若幹機器内部署了一台。
下面介紹基本的性能分析和故常排查方法。
3
比如可以在dashboard中檢視到具體某個時間段整個系統的穩定程度，我們在圖上看到了一個異常波峰，時間在早上6點左右，通過清單篩選器移除WEB External 後看圖。
1
其他業務都很正常，執行到最後php層，平均時間也隻用了10ms左右。回到上圖點選波峰的訓示器可以看到具體明細。
2
當打開詳情時可以明顯看到，原來是微信的接口在6點鐘抽了。同樣該頁面還可以監控到第三方服務調用的響應情況。比如217ms的api.hitokoto.us服務。
再簡單看一個SQL緩慢的監控。
我通過web事務的響應時間占比檢視到一個腳本執行時間相對過長，通過上圖可以看到資料庫查詢占了579ms
1
通過切換到詳情頁面，可以看到整個腳本的調用過程，最終發現是程式mysqli.php:88行執行的查詢占用了過長的時間。
以上隻是通過OneAPM持續檢查程式穩定性的一個基本方法。
程式在日常運作中由于受到的通路量不同，很有可能在某個時間點上出現大面積的延遲，比如并發突然增高或通路某一部分接口的比例突然過高，而平時apdex名額卻看起來非常漂亮，那麼這個時候通過OneAPM就很容易發現程式中影響性能的部分，進而繼續改進或優化代碼。
轉載于:https://blog.51cto.com/liuqh/1771562