當前位置:才華齋>計算機>php語言>

分析PHP效能調優實戰

php語言 閱讀(2.15W)

效能調優時的最好的選擇是首先確保執行儘可能少的程式碼。以下是小編整理的分析PHP效能調優實戰,就跟隨小編去了解下吧,想了解更多相關資訊請持續關注我們應屆畢業生考試網!

分析PHP效能調優實戰

  效能調優

不用執行的程式碼才是絕好的程式碼。其他只是好的程式碼。所以,效能調優時,最好的選擇是首先確保執行儘可能少的程式碼。

  OpCode 快取

首先,最快且最簡單的選擇是啟用 OpCode 快取。OpCode 快取的更多資訊可以在 這裡 找到。

  PHP 效能分析第三篇: 效能調優實戰

在上圖,我們看到啟用 Zend OpCache 後發生的情況。最後一行是我們的基準,也即沒有啟用快取的情況。

在中間行,我們看到較小的效能提升,以及記憶體使用量的大幅減少。小的效能提升(很可能)來自 Zend OpCache 優化,而非 OpCode 快取。

第一行是優化和 OpCode 快取後結果,我們看到很大的效能提升。

  PHP 效能分析第三篇: 效能調優實戰

現在,我們看看 APC 之前和之後的變化。如上圖所示,跟 Zend OpCache 相比,隨著快取的建立,我們看到初始(中間行)請求的效能下降,在消耗時長與記憶體使用量方面的表現都明顯下降。

接著,隨之 opcode 快取的建立,我們看到類似的效能提升。

  內容快取

第二件我們能做的事是快取內容——這對 WordPress 而言小菜一碟。它提供了許多安裝簡便的外掛來實現內容快取,包括 WP Super Cache。WP Super Cache 會建立網站的靜態版本。該版本會在出現諸如評論事件時依照網站設定自動過期。(例如,在非常高負載情況下,您可能會想禁止任何原因造成的快取過期)。

內容快取只能在幾乎沒有寫操作時有效執行,寫操作會使快取失效,而讀操作不會。

你也應該快取應用從第三方 API 處收到的內容,從而減少由於 API 可用性導致的延遲與依賴。 WordPress 有兩個快取外掛,可以大大提高網站的效能: W3 Total Cache 和 WP Super Cache。

這兩個外掛都會建立網站的靜態 HTML 副本,而不是每次收到請求時再生成頁面,從而壓縮響應時間。

如果你正在開發自己的應用程式,大多數框架都有快取模組:

Zend framework 2:ZendCache

Symfony 2:Multiple options

Laravel 4:Laravel Cache

ThinkPHP 3.2.3:ThinkPHP Cache

  查詢快取

另一個快取選項是查詢快取。針對 MySQL,有一個通用的查詢快取幫助極大。對於其他資料庫,將查詢結果集快取在 Memcached 或者 cassandra 這樣的記憶體快取,也非常有效。

跟內容快取一樣,查詢快取在包含大量讀取操作的場景是最有效的`。由於少量的資料改動就會使大塊的快取區無效,尤其不能在這種情況下依賴 MySQL 查詢快取來提高效能。

查詢快取或許在生成內容快取時對效能有提升。

如下圖所示,當我們開啟查詢快取後,實際執行時間減少了 40% ,儘管記憶體使用量沒有明顯改變。

現有三種類型的快取選項,由 query_cache_type 控制設定。

設定值為 0 或 OFF 將禁用快取

設定值為 1 或 ON 將快取除了以 SELECT SQL_NO_CACHE 開頭之外的所有選擇

設定值為 2 或 DEMAND 只會快取以 SELECT SQL_CACHE 開頭的選擇

此外,你應該將 query_cache_size 設定為非零值。將它設定為零將禁用快取,不管 query_cache_type 是否設定。

想得到設定快取的幫助,與許多其他效能相關的設定,請檢視 mysql-tuning-primer 指令碼。

MySQL 查詢快取的主要問題是,它是全域性的。對快取結果集構成的表格的任何更改都將導致快取失效。在寫入操作頻繁的應用程式中,這將使快取幾乎無效。

然而,你還有許多其他選擇,可以根據你的需求和資料集建立更多的智慧快取,例如 Memcached , riak , cassandra 或 redis

  查詢優化

如前所述,資料庫查詢常常是程式執行緩慢的原因,查詢優化往往能比程式碼優化帶來更多切身的好處。

查詢優化有助於生成內容快取時提高效能,而且,在無法快取這種最壞的情況下也有益處。

除了分析, MySQL 還有一個幫助識別慢查詢的選擇——慢查詢日誌。慢查詢日誌會記錄所有耗時超過指定時間的查詢,以及不使用索引的查詢(後者為可選項)。

您可以在 中使用以下配置啟用日誌。

[mysqld]

log_slow_queries =/var/log/mysql/

long_query_time =1

log-queries-not-using-indexes

任何查詢如果慢於 long_query_time (以秒為單位),該查詢就會記錄到日誌檔案 log_slow_queries 中。預設值是10秒,最低1秒。

此外, log-queries-not-using-indexes 選項可以將任何不使用索引的查詢捕獲到日誌中。

之後我們可以用與 MySQL 捆綁在一起的 mysqldumpslow 命令檢查日誌。

在 WordPress 安裝時使用這些選項 ,主頁載入完成並執行後得到如下資料:

$ mysqldumpslow -g "wp_" /var/log/mysql/

Reading mysql slow query log from /var/log/mysql/

Count: 1 Time=0.00s (0s) Lock=0.00s (0s) Rows=358.0(358), user[user]@[host] SELECT option_name, option_value FROM wp_options WHERE autoload ='S'

Count: 1 Time=0.00s (0s) Lock=0.00s (0s) Rows=41.0(41), user[user]@[host] SELECT user_id, meta_key, meta_value FROM wp_usermeta WHERE user_id IN (N)

首先,注意所有字串值都以 S 表示,數字則以 N 表示。你可以新增 -a 標誌來顯示這些值。