性能調優時的最好的選擇是首先確保運行儘可能少的代碼。以下是小編整理的分析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 標誌來顯示這些值。