PHP 7.0 安裝使用與性能監測！

PHP 7.0發佈，網上關於新版的介紹不少，介於 7.0 在正式發佈以前已經發過若干個 Beta、8個 RC，應該不會出現重大問題。今日我將一臺機器升級至 PHP 7.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/ https://github.com/rlerdorf/php-memcached

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.html

異常處理與解決

在配置完成後，就須要實際的將程序跑一下了。目前將老系統轉移到 EN 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 官方網站已經提供了下載。截止本文落筆，PHP 7.0版本官方提供了一個下載地址是：<a href="https://oneapm.kf5.com/attachments/download/366552/0015667f0036f47c827fcb8fcbfbc79/" target="_blank">https://oneapm.kf5.com/attachments/download/366552/0015667f0036f47c827fcb8fcbfbc79/</a>

在這以前更多人會使用 xhprof 來檢測和優化系統，可是 xhprof 對總體的程序性能採集樣本沒法很好的概括，也沒有很好的可視化曲線圖和 Web 事務跟蹤，致使在短期內很難對系統瓶頸進行評估。

因此我使用 OneAPM 的 PHP Agent 來完成這些工做，OneAPM 一樣使用定時採樣定時彙報的方式來收集性能信息，而且官方宣稱耗費資源小於5%。不過對於使用性能提高數倍的 PHP7.0 來部署的話這些損耗能夠忽略不計，並且本人只在集羣若干機器內部署了一臺。

下面介紹基本的性能分析和故常排查方法。

好比能夠在 dashboard 中查看到具體某個時間段整個系統的穩定程度，咱們在圖上看到了一個異常波峯，時間在早上6點左右，經過列表篩選器移除 WEB External 後看圖。

其餘業務都很正常，執行到最後 PHP 層，平均時間也只用了 10ms 左右。回到上圖點擊波峯的指示器能夠看到具體明細。

當打開詳情時能夠明顯看到，原來是微信的接口在6點鐘抽了。一樣該頁面還能夠監控到第三方服務調用的響應狀況。好比 217ms 的 api.hitokoto.us 服務。

再簡單看一個 SQL 緩慢的監控。

經過 Web 事務的響應時間佔比查看到一個腳本執行時間相對過長，經過上圖能夠看到數據庫查詢佔了579ms

經過切換到詳情頁面，能夠看到整個腳本的調用過程，最終發現是程序 <span class="s1">mysqli.php:88 行執行的查詢佔用了過長的時間。</span>

以上只是經過 OneAPM 持續檢查程序穩定性的一個基本方法。

程序在平常運行中因爲受到的訪問量不一樣，頗有可能在某個時間點上出現大面積的延遲，好比並發忽然增高或訪問某一部分接口的比例忽然太高，而平時 Apdex 指標卻看起來很是漂亮，那麼這個時候經過 OneAPM 就很容易發現程序中影響性能的部分，從而繼續改進或優化代碼。

（本文做者系 OneAPM 用戶，受權 OneAPM 官方博客轉發）

OneAPM for PHP 可以深刻到全部 PHP 應用內部完成應用性能管理和監控，包括代碼級別性能問題的可見性、性能瓶頸的快速識別與追溯、真實用戶體驗監控、服務器監控和端到端的應用性能管理。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客 。 本文轉自 OneAPM 官方博客