php效能調優
第一章 針對系統呼叫過多的優化
我這次的優化針對syscall呼叫過多的問題,所以使用strace跟蹤apache進行分析。
1. apache2ctl -X &
使用-X(debug)引數啟動httpd程式,這個時候只啟動1個httpd程式
2. ps -ef | grep httpd
找到需要strace的pid
3. strace -p $PID -o /tmp/strace.log
傳送一個http請求到httpd,就能看到strace資訊了。
一、include_path問題
一般可以看到很多這類資訊:
stat64(“/error/dir/test.php”, 0xbfab4b9c) = -1 ENOENT (No such file or directory)
解決方法:
1. 在應用php裡面設定include_path,去掉`.`等相對路徑,將其中包含使用檔案比較多的目錄放到前面。保證遍歷include_path的時候能夠很快找到。
2. 使用絕對路徑進行include,require,include_once,require_once
3. 使用php的自動載入機制
二、apache的rewrite配置
RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d
RewriteRule .* %{DOCUMENT_ROOT}%/index.php
#RewriteRule .* /index.php
這裡最後一個註釋掉的rewrite配置不好,因為它每次請求都會多一次syscall
stat64(“/index.php”, 0xbfab4b9c) = -1 ENOENT (No such file or directory)
三、apache日誌問題
我們在測試一個問題的時候,發現如果自定義日誌裡面記錄了訪問時間等資訊,會多出很多
stat64(“/etc/localtime”, {st_mode=S_IFREG|0644, st_size=165, …}) = 0
如果記錄的日誌比較多,效能下降非常嚴重,對於簡單應用,記錄複雜日誌,效能會下降30倍。
解決方法:
在多個apache前端架http層的proxy,如haproxy,nginx。在這些地方記錄日誌。接入層負載一般不高,所以proxy可以做一些記錄日誌的工作。在這種配置下,可以關閉apache的日誌。
四、realpath()問題
大家可以看一下這篇文章:http://bugs.php.net/bug.php?id=43864
lstat64呼叫多了之後,主機CPU和IO都會比較高。
究其原因,因為php5.2.x對realpath()的實現不夠好,導致會針對目錄層次,逐級呼叫lstat64()。
為了解決這個問題,它使用了realpath_cache,針對某個檔案,儲存其realpath。這裡只儲存了葉子節點的realpath,而對 路徑上的內容沒有儲存,所以在做“/a/b/c/d/e/f/g/a.php”realpath檢查的時候逐級呼叫lstat64,而在做“/a/b/c /d/e/f/g/b.php”檢查的時候,還要對“”/a/b/c/d/e/f/g/”做逐級檢查。所以有些優化建議就是“減少目錄層次,甚至放到“/”根目錄下”。當然我不推薦這麼幹。從5.3.0開始,php對realpath()做了高效的實現,路realpath的中間路徑也做了快取,以上面的情況為例,檢查“/a/b/c/d/e/f/g/b.php”的時候就只會做“b.php”的檢查了。所以,升級到php5.3.0以上版本能夠很好地解決這個問題。
解決方法:
1. 儘量少用include_once和require_once
因為這兩個函式會做realpath檢查,防止有符號連結的情況導致重複載入。不用它們就能減少realpath的呼叫。
2. 合理設定php.ini中的realpath_cache_size和realpath_cache_ttl引數
既然使用了realpath_cache,那肯定有大小限制。對於使用了很多檔案,比如用了Zend Framework的專案,可能預設realpath_cache_size=16k就太小了,需要增大這個設定,推薦設定為256K以上。另外預設realpath_cache_ttl=120,2分鐘就過時了,怎麼也要設定為3600(1小時)。
這裡需要注意的是,這個realpath_cache是每隔apache程式獨佔的,所以很吃記憶體的,不能設定的太大。
3. 升級到php5.3.x
沒什麼好說的,如果應用經過詳細測試沒有問題,那麼推薦升級到高版本。
五、APC的使用
apc能夠快取php的opcode碼,能普遍提升30%的效能。但是預設apc.stat=1,這樣每次請求都會訪問需要使用的php檔案,看看這個檔案是否更新了,已決定是否重新編譯php檔案。這個是很耗效能的,推薦關掉。
解決方法:
1. 設定apc.stat=0,不必每次請求都訪問需要用到的php檔案。
需要注意的是:每次發版本改動了php檔案的時候,必須呼叫apc_clear()清除apc快取,否則你的程式碼永遠也不會生效。
六、smarty調優
對於模組化比較好,而且應用比較多的網站,如果使用了smarty模板系統,這個時候就需要對smarty進行調優了,否則smarty部分的開銷就很可觀。之前根據一個經驗來看,smarty可以佔到10%左右的開銷。
預設配置下,smarty對檢測每個模板檔案是否有更新,決定是否重新編譯模板檔案。如果模板檔案比較多,則會多出很多stat系統呼叫,加上context switch,開銷會不小。
解決方法:
1. $smarty->compile_check = false;
去掉每次的檢測,但是這樣之後,每次發版本都要把compile_dir目錄的已編譯模板刪除,否則你的模板檔案永遠也不會生效了。
2. 如果可能,可以使用cache功能。
結論
經過上面的調優,結論如下:
1. 升級到php5.3.1開啟上面的優化,比5.2.3效能高10%以上
2. 在優化配置下,使用Zend Framework開發的一個搜尋應用,每秒請求可達210/rps
3. 在優化配置下,使用doophp framework開發的一個搜尋應用,每秒請求可達450/rps
第二章 使用APC快取
php程式的執行流程
—》客戶端(瀏覽器)請求Get hello.php
—-》cgi伺服器接(譬如apache)收到請求,根據配置尋找php的處理程式(譬如mod_php)
—-》apache載入php的處理程式,php的處理程式讀取php.ini初始化php的解釋環境
—-》mod_php定位尋找hell.php,將其載入到記憶體中來
—-》mod_php編譯原始碼成為opcode樹
—-》mod_php執行opcode樹
—-》生成結果給瀏覽器
在這個過程中,有幾點是需要注意的:
1、 對許多程式碼檔案說,特別是含有很多包含檔案(include or require)。它們需要花費更多的時間和解析併產生中間程式碼。
2、 即使PHP程式碼檔案沒有發生改變,這個執行過程還會嚴格的按照流程執行。也就是說,無論你的應該程式是否發生改變,每次呼叫的時候,都需要重新編譯生成opcode碼。(其實這就是編譯快取存在的理由)
3、 這個流程不僅僅發生在主要的程式碼檔案,對於每一次的include和require來說,都會執行這個流程。(這是可以繼續優化的)
那些地方可以優化呢?
1、將mod_php fast-cgi化,避免每次都要載入這個模組,這個模組還要每次都去初始化php的解釋環境。
2、快取php檔案的opcode碼,這樣話,避免每次都去編譯。
APC可用用來實現第2點。編譯快取去掉了執行PHP過程中的解析過程,所以它對含有大量PHP程式碼的應用程式是非常有效的。通常情況下可以提升2-3倍以上的速度。對於包含大量include檔案的專案,編譯快取更現實出它的優越性。
注:include並不會被編譯快取進行快取。比如現在有兩個檔案:main.php 和tobeInclude.php,其中main.php中有這樣的語句include tobeInclude.php’。假設中間碼的字尾為.op(實際上不是這樣)。那麼加上快取cache後 main.php=>main.op ,tobeInclude.php=>tobeInclude.op。但是PHP在執行main.php的時候,她還是需要去解析main.op中的include命令,去呼叫tobeInclude.op的內容。具體流程是這樣的。
…=>執行main.op=>執行tobeInclude.op=>…
而不是之間簡單的執行main.op
所以說“過多的include檔案會降低程式效能的”。
APC的具體配置。
Alternative PHP Cache(APC)是 PHP 的一個免費公開的優化程式碼快取。它用來提供免費,公開並且強健的架構來快取和優化 PHP 的中間程式碼。
APC 官方網站為 http://pecl.php.net/package/apc
1、安裝
以PHP extension 形式安裝
phpize
./configure –enable-apc –enable-apc-mmap
make
make install
生成.so,將.so拷貝到php引用modules的目錄下,修改許可權755
2、配置
apc.enabled boolean
apc.optimization optimization
選項在指令碼中可以改變
APC PHP.ini配置選項詳解
[APC]
; Alternative PHP Cache 用於快取和優化PHP中間程式碼
apc.cache_by_default = On
;SYS
; 是否預設對所有檔案啟用緩衝。
; 若設為Off並與以加號開頭的apc.filters指令一起用,則檔案僅在匹配過濾器時才被快取。
apc.enable_cli = Off
;SYS
; 是否為CLI版本啟用APC功能,僅用於測試和除錯目的才開啟此指令。
apc.enabled = On
; 是否啟用APC,如果APC被靜態編譯進PHP又想禁用它,這是唯一的辦法。
apc.file_update_protection = 2
;SYS
; 當你在一個執行中的伺服器上修改檔案時,你應當執行原子操作。
; 也就是先寫進一個臨時檔案,然後將該檔案重新命名(mv)到最終的名字。
; 文字編輯器以及 cp, tar 等程式卻並不是這樣操作的,從而導致有可能緩衝了殘缺的檔案。
; 預設值 2 表示在訪問檔案時如果發現修改時間距離訪問時間小於 2 秒則不做緩衝。
; 那個不幸的訪問者可能得到殘缺的內容,但是這種壞影響卻不會通過快取擴大化。
; 如果你能確保所有的更新操作都是原子操作,那麼可以用 0 關閉此特性。
; 如果你的系統由於大量的IO操作導致更新緩慢,你就需要增大此值。
apc.filters =
;SYS
; 一個以逗號分隔的POSIX擴充套件正規表示式列表。
; 如果原始檔名與任意一個模式匹配,則該檔案不被快取。
; 注意,用來匹配的檔名是傳遞給include/require的檔名,而不是絕對路徑。
; 如果正規表示式的第一個字元是“+”則意味著任何匹配表示式的檔案會被快取,
; 如果第一個字元是“-“則任何匹配項都不會被快取。“-“是預設值,可以省略掉。
apc.ttl = 0
;SYS
; 快取條目在緩衝區中允許逗留的秒數。0 表示永不超時。建議值為7200~36000。
; 設為 0 意味著緩衝區有可能被舊的快取條目填滿,從而導致無法快取新條目。
apc.user_ttl = 0
;SYS
; 類似於apc.ttl,只是針對每個使用者而言,建議值為7200~36000。
; 設為 0 意味著緩衝區有可能被舊的快取條目填滿,從而導致無法快取新條目。
apc.gc_ttl = 3600
;SYS
; 快取條目在垃圾回收表中能夠存在的秒數。
; 此值提供了一個安全措施,即使一個伺服器程式在執行快取的原始檔時崩潰,
; 而且該原始檔已經被修改,為舊版本分配的記憶體也不會被回收,直到達到此TTL值為止。
; 設為零將禁用此特性。
apc.include_once_override = Off
;SYS
; 請保持為Off,否則可能導致意想不到的結果。
apc.max_file_size = 1M
;SYS
; 禁止大於此尺寸的檔案被快取。
apc.mmap_file_mask =
;SYS
; 如果使用–enable-mmap(預設啟用)為APC編譯了MMAP支援,
; 這裡的值就是傳遞給mmap模組的mktemp風格的檔案掩碼(建議值為“/tmp/apc.XXXXXX”)。
; 該掩碼用於決定記憶體對映區域是否要被file-backed或者shared memory backed。
; 對於直接的file-backed記憶體對映,要設定成“/tmp/apc.XXXXXX”的樣子(恰好6個X)。
; 要使用POSIX風格的shm_open/mmap就需要設定成“/apc.shm.XXXXXX”的樣子。
; 你還可以設為“/dev/zero”來為匿名對映的記憶體使用核心的“/dev/zero”介面。
; 不定義此指令則表示強制使用匿名對映。
apc.num_files_hint = 1000
;SYS
; Web伺服器上可能被包含或被請求的不同原始檔的大致數量(建議值為1024~4096)。
; 如果你不能確定,則設為 0 ;此設定主要用於擁有數千個原始檔的站點。
apc.optimization = 0
; 優化級別(建議值為 0 ) 。
; 正整數值表示啟用優化器,值越高則使用越激進的優化。
; 更高的值可能有非常有限的速度提升,但目前尚在試驗中。
apc.report_autofilter = Off
;SYS
; 是否記錄所有由於early/late binding原因而自動未被快取的指令碼。
apc.shm_segments = 1
;SYS
; 為編譯器緩衝區分配的共享記憶體塊數量(建議值為1)。
; 如果APC耗盡了共享記憶體,並且已將apc.shm_size指令設為系統允許的最大值,
; 你可以嘗試增大此值。
apc.shm_size = 30
;SYS
; 每個共享記憶體塊的大小(以MB為單位,建議值為128~256)。
; 有些系統(包括大多數BSD變種)預設的共享記憶體塊大小非常少。
apc.slam_defense = 0
;SYS(反對使用該指令,建議該用apc.write_lock指令)
; 在非常繁忙的伺服器上,無論是啟動服務還是修改檔案,
; 都可能由於多個程式企圖同時快取一個檔案而導致競爭條件。
; 這個指令用於設定程式在處理未被快取的檔案時跳過快取步驟的百分率。
; 比如設為75表示在遇到未被快取的檔案時有75%的概率不進行快取,從而減少碰撞機率。
; 鼓勵設為 0 來禁用這個特性。
apc.stat = On
;SYS
; 是否啟用指令碼更新檢查。
; 改變這個指令值要非常小心。
; 預設值 On 表示APC在每次請求指令碼時都檢查指令碼是否被更新,
; 如果被更新則自動重新編譯和快取編譯後的內容。但這樣做對效能有不利影響。
; 如果設為Off 則表示不進行檢查,從而使效能得到大幅提高。
; 但是為了使更新的內容生效,你必須重啟Web伺服器。
; 這個指令對於include/require的檔案同樣有效。但是需要注意的是,
; 如果你使用的是相對路徑,APC就必須在每一次include/require時都進行檢查以定位檔案。
; 而使用絕對路徑則可以跳過檢查,所以鼓勵你使用絕對路徑進行include/require操作。
apc.user_entries_hint = 100
;SYS
; 類似於num_files_hint指令,只是針對每個不同使用者而言。
; 如果你不能確定,則設為 0 。
apc.write_lock = On
;SYS
; 是否啟用寫入鎖。
; 在非常繁忙的伺服器上,無論是啟動服務還是修改檔案,
; 都可能由於多個程式企圖同時快取一個檔案而導致競爭條件。
; 啟用該指令可以避免競爭條件的出現。
apc.rfc1867 = Off
;SYS
; 開啟該指令後,對於每個恰好在file欄位之前含有APC_UPLOAD_PROGRESS欄位的上傳檔案,APC都將自動建立一個upload_的使用者快取條目(就是APC_UPLOAD_PROGRESS欄位值)。
3、php函式
apc_cache_info – Retrieves cached information (and meta-data) from APC`s data store
apc_clear_cache – Clears the APC cache
apc_define_constants – Defines a set of constants for later retrieval and mass-definition
apc_delete – Removes a stored variable from the cache
apc_fetch – Fetch a stored variable from the cache
apc_load_constants – Loads a set of constants from the cache
apc_sma_info – Retrieves APC`s Shared Memory Allocation information
apc_store – Cache a variable in the data store
4、注意:
Apc與apache的程式共享記憶體,所以只有在執行apache程式時,才可以往apc中存值,普通的php程式不能訪問apc共享記憶體。
第三章 提高PHP效能的編碼技巧
0、用單引號代替雙引號來包含字串,這樣做會更快一些。因為PHP會在雙引號包圍的字串中搜尋變數,單引號則不會,注意:只有echo能這麼做,它是一種可以把多個字串當作引數的“函式”(譯註:PHP手冊中說echo是語言結構,不是真正的函式,故把函式加上了雙引號)。
1、如果能將類的方法定義成static,就儘量定義成static,它的速度會提升將近4倍。
2、$row[’id’] 的速度是$row[id]的7倍。
3、echo 比print 快,並且使用echo的多重引數(譯註:指用逗號而不是句點)代替字串連線,比如echo $str1,$str2。
4、在執行for迴圈之前確定最大迴圈數,不要每迴圈一次都計算最大值,最好運用foreach代替。
5、登出那些不用的變數尤其是大陣列,以便釋放記憶體。
6、儘量避免使用__get,__set,__autoload。
7、require_once()代價昂貴。
8、include檔案時儘量使用絕對路徑,因為它避免了PHP去include_path裡查詢檔案的速度,解析作業系統路徑所需的時間會更少。
9、如果你想知道指令碼開始執行(譯註:即伺服器端收到客戶端請求)的時刻,使用$_SERVER[‘REQUEST_TIME’]要好於time()。
10、函式代替正規表示式完成相同功能。
11、str_replace函式比preg_replace函式快,但strtr函式的效率是str_replace函式的四倍。
12、如果一個字串替換函式,可接受陣列或字元作為引數,並且引數長度不太長,那麼可以考慮額外寫一段替換程式碼,使得每次傳遞引數是一個字元,而不是隻寫一行程式碼接受陣列作為查詢和替換的引數。
13、使用選擇分支語句(譯註:即switch case)好於使用多個if,else if語句。
14、用@遮蔽錯誤訊息的做法非常低效,極其低效。
15、開啟apache的mod_deflate模組,可以提高網頁的瀏覽速度。
16、資料庫連線當使用完畢時應關掉,不要用長連線。
17、錯誤訊息代價昂貴。
18、在方法中遞增區域性變數,速度是最快的。幾乎與在函式中呼叫區域性變數的速度相當。
19、遞增一個全域性變數要比遞增一個區域性變數慢2倍。
20、遞增一個物件屬性(如:$this->prop++)要比遞增一個區域性變數慢3倍。
21、遞增一個未預定義的區域性變數要比遞增一個預定義的區域性變數慢9至10倍。
22、僅定義一個區域性變數而沒在函式中呼叫它,同樣會減慢速度(其程度相當於遞增一個區域性變數)。PHP大概會檢檢視是否存在全域性變數。
23、方法呼叫看來與類中定義的方法的數量無關,因為我(在測試方法之前和之後都)新增了10個方法,但效能上沒有變化。
24、派生類中的方法執行起來要快於在基類中定義的同樣的方法。
25、呼叫帶有一個引數的空函式,其花費的時間相當於執行7至8次的區域性變數遞增操作。類似的方法呼叫所花費的時間接近於15次的區域性變數遞增操作。
26、Apache解析一個PHP指令碼的時間要比解析一個靜態HTML頁面慢2至10倍。儘量多用靜態HTML頁面,少用指令碼。
27、除非指令碼可以快取,否則每次呼叫時都會重新編譯一次。引入一套PHP快取機制通常可以提升25%至100%的效能,以免除編譯開銷。
28、儘量做快取,可使用memcached。memcached是一款高效能的記憶體物件快取系統,可用來加速動態Web應用程式,減輕資料庫負載。對運算碼(OP code)的快取很有用,使得指令碼不必為每個請求做重新編譯。
29、當操作字串並需要檢驗其長度是否滿足某種要求時,你想當然地會使用strlen()函式。此函式執行起來相當快,因為它不做任何計算,只返回在zval 結構(C的內建資料結構,用於儲存PHP變數)中儲存的已知字串長度。但是,由於strlen()是函式,多多少少會有些慢,因為函式呼叫會經過諸多步驟,如字母小寫化(譯註:指函式名小寫化,PHP不區分函式名大小寫)、雜湊查詢,會跟隨被呼叫的函式一起執行。在某些情況下,你可以使用isset() 技巧加速執行你的程式碼。
(舉例如下)
if (strlen($foo) < 5) { echo “Foo is too short”$$ }
(與下面的技巧做比較)
if (!isset($foo{5})) { echo “Foo is too short”$$ }
呼叫isset()恰巧比strlen()快,因為與後者不同的是,isset()作為一種語言結構,意味著它的執行不需要函式查詢和字母小寫化。也就是說,實際上在檢驗字串長度的頂層程式碼中你沒有花太多開銷。
34、當執行變數$i的遞增或遞減時,$i++會比++$i慢一些。這種差異是PHP特有的,並不適用於其他語言,所以請不要修改你的C或Java程式碼並指望它們能立即變快,沒用的。++$i更快是因為它只需要3條指令(opcodes),$i++ 則需要4條指令。後置遞增實際上會產生一個臨時變數,這個臨時變數隨後被遞增。而前置遞增直接在原值上遞增。這是最優化處理的一種,正如Zend的PHP 優化器所作的那樣。牢記這個優化處理不失為一個好主意,因為並不是所有的指令優化器都會做同樣的優化處理,並且存在大量沒有裝配指令優化器的網際網路服務提供商(ISPs)和伺服器。
35、並不是事必物件導向(OOP),物件導向往往開銷很大,每個方法和物件呼叫都會消耗很多記憶體。
36、並非要用類實現所有的資料結構,陣列也很有用。
37、不要把方法細分得過多,仔細想想你真正打算重用的是哪些程式碼?
38、當你需要時,你總能把程式碼分解成方法。
39、儘量採用大量的PHP 內建函式。
40、如果在程式碼中存在大量耗時的函式,你可以考慮用C擴充套件的方式實現它們。
41、評估檢驗(profile)你的程式碼。檢驗器會告訴你,程式碼的哪些部分消耗了多少時間。Xdebug偵錯程式包含了檢驗程式,評估檢驗總體上可以顯示出程式碼的瓶頸。
42、mod_zip可作為Apache模組,用來即時壓縮你的資料,並可讓資料傳輸量降低80%。
43、在可以用file_get_contents替代file、fopen、feof、fgets等系列方法的情況下,儘量用file_get_contents,因為他的效率高得多!但是要注意file_get_contents在開啟一個URL檔案時候的PHP版本問題;
44、儘量的少進行檔案操作,雖然PHP的檔案操作效率也不低的;
45、優化Select SQL語句,在可能的情況下儘量少的進行Insert、Update操作;
46、儘可能的使用PHP內部函式(但是我卻為了找個PHP裡面不存在的函式,浪費了本可以寫出一個自定義函式的時間,經驗問題啊!);
47、迴圈內部不要**變數,尤其是大變數:物件(這好像不只是PHP裡面要注意的問題吧?);
48、多維陣列儘量不要迴圈巢狀賦值;
49、在可以用PHP內部字串操作函式的情況下,不要用正規表示式;
50、foreach效率更高,儘量用foreach代替while和for迴圈;
51、用單引號替代雙引號引用字串;
52、“用i+=1代替i=i+1。符合c/c++的習慣,效率還高”;
53、對global變數,應該用完就unset()掉;
作者:Tyler Ning
出處:http://www.cnblogs.com/tylerdonet/
本文版權歸作者和部落格園共有,歡迎轉載,但未經作者同意必須保留此段宣告,且在文章頁面明顯位置給出原文連線,如有問題,可以通過以下郵箱地址williamningdong@gmail.com
聯絡我,非常感謝。
相關文章
- php調優PHP
- Spark 效能調優--資源調優Spark
- 【效能調優】效能測試、分析與調優基礎
- php效能優化PHP優化
- ElasticSearch效能調優Elasticsearch
- adnroid效能調優
- 效能調優學習之硬體調優
- PHP 效能優化 - OPcachePHP優化opcache
- 效能調優實戰
- Linux之效能調優Linux
- 效能監控調優
- linux調優效能命令Linux
- .Net效能調優-ArrayPool
- .Net效能調優-MemoryPool
- PHP 效能優化 - php.ini 配置PHP優化
- TiDB 效能分析&效能調優&優化實踐大全TiDB優化
- Nginx安全優化與效能調優Nginx優化
- solr研磨之效能調優Solr
- Kafka 線上效能調優Kafka
- 2. 效能調優概述
- java效能調優記錄Java
- android效能調優詳解Android
- 效能調優命令之jstackJS
- 淺談Nginx效能調優Nginx
- PHP效能優化 -理論篇PHP優化
- 【譯】React 應用效能調優React
- Spark學習——效能調優(一)Spark
- Spark學習——效能調優(二)Spark
- Spark學習——效能調優(三)Spark
- java效能調優記錄(限流)Java
- 記一次效能調優
- go效能調優之火焰圖Go
- 深入理解JVM效能調優JVM
- Oracle 效能調優工具:SQL MonitorOracleSQL
- 效能調優五步法
- 效能調優的通用準則
- MySQL入門--效能調優概述MySql
- Linux系統效能調優技巧Linux
- 效能調優——SQL最佳化SQL