php性能調優

第一章  針對系統調用過多的優化php

我此次的優化針對syscall調用過多的問題,因此使用strace跟蹤apache進行分析。前端

1.  apache2ctl -X &nginx

使用-X(debug)參數啓動httpd進程,這個時候只啓動1httpd進程c++

2. ps -ef | grep httpd正則表達式

找到須要stracepid數據庫

3. strace -p $PID -o /tmp/strace.logapache

發送一個http請求到httpd,就能看到strace信息了。數組

 

1、include_path問題瀏覽器

通常能夠看到不少這類信息:緩存

stat64("/error/dir/test.php", 0xbfab4b9c) = -1 ENOENT (No such file or directory)

解決方法:

1. 在應用php裏面設置include_path,去掉'.'等相對路徑,將其中包含使用文件比較多的目錄放到前面。保證遍歷include_path的時候可以很快找到。

2. 使用絕對路徑進行includerequireinclude_oncerequire_once

3. 使用php自動加載機制

 

2、apacherewrite配置

    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)

 

3、apache日誌問題

咱們在測試一個問題的時候,發現若是自定義日誌裏面記錄了訪問時間等信息,會多出不少

stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=165, ...}) = 0

若是記錄的日誌比較多,性能降低很是嚴重,對於簡單應用,記錄複雜日誌,性能會降低30倍。

解決方法:

在多個apache前端架http層的proxy,如haproxynginx。在這些地方記錄日誌。接入層負載通常不高,因此proxy能夠作一些記錄日誌的工做。在這種配置下,能夠關閉apache的日誌

 

4、realpath()問題

你們能夠看一下這篇文章:http://bugs.php.net/bug.php?id=43864

lstat64調用多了以後,主機CPUIO都會比較高。

究其緣由,由於php5.2.xrealpath()的實現不夠好,致使會針對目錄層次,逐級調用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開始,phprealpath()作了高效的實現,路realpath的中間路徑也作了緩存,以上面的狀況爲例,檢查"/a/b/c/d/e/f/g/b.php"的時候就只會作「b.php」的檢查了。因此,升級到php5.3.0以上版本可以很好地解決這個問題。

解決方法:

1. 儘可能少用include_oncerequire_once

由於這兩個函數會作realpath檢查,防止有符號連接的狀況致使重複加載。不用它們就能減小realpath的調用。

2. 合理設定php.ini中的realpath_cache_sizerealpath_cache_ttl參數

既然使用了realpath_cache,那確定有大小限制。對於使用了不少文件,好比用了Zend Framework的項目,可能默認realpath_cache_size=16k就過小了,須要增大這個設置,推薦設置爲256K以上。另外默認realpath_cache_ttl=1202分鐘就過期了,怎麼也要設定爲36001小時)。

這裏須要注意的是,這個realpath_cache是每隔apache進程獨佔的,因此很吃內存的,不能設置的太大。

3. 升級到php5.3.x

沒什麼好說的,若是應用通過詳細測試沒有問題,那麼推薦升級到高版本。

 

5、APC的使用

apc可以緩存phpopcode碼,能廣泛提高30%的性能。可是默認apc.stat=1,這樣每次請求都會訪問須要使用的php文件,看看這個文件是否更新了,已決定是否從新編譯php文件。這個是很耗性能的,推薦關掉。

解決方法:

1. 設定apc.stat=0,沒必要每次請求都訪問須要用到的php文件。

須要注意的是:每次發版本改動了php文件的時候,必須調用apc_clear()清除apc緩存,不然你的代碼永遠也不會生效。

6、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
—-
》生成結果給瀏覽器

在這個過程當中,有幾點是須要注意的:

一、  對許多代碼文件說,特別是含有不少包含文件(include or require)。它們須要花費更多的時間和解析併產生中間代碼。

二、  即便PHP代碼文件沒有發生改變,這個執行過程還會嚴格的按照流程執行。也就是說,不管你的應該程序是否發生改變,每次調用的時候,都須要從新編譯生成opcode碼。(其實這就是編譯緩存存在的理由)

三、  這個流程不只僅發生在主要的代碼文件,對於每一次的includerequire來講,都會執行這個流程。(這是能夠繼續優化的)

那些地方能夠優化呢?

一、mod_php fast-cgi化,避免每次都要加載這個模塊,這個模塊還要每次都去初始化php的解釋環境。

二、緩存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 CacheAPC)是 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"的樣子(剛好6X)

; 要使用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字段值)

3php函數

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注意:

Apcapache的進程共享內存,因此只有在執行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文件時儘可能使用絕對路徑,由於它避免了PHPinclude_path裏查找文件的速度,解析操做系統路徑所需的時間會更少。
9
、若是你想知道腳本開始執行(譯註:即服務器端收到客戶端請求)的時刻,使用$_SERVER[‘REQUEST_TIME’]要好於time()
10
、函數代替正則表達式完成相同功能。
11
str_replace函數比preg_replace函數快,但strtr函數的效率是str_replace函數的四倍。
12
、若是一個字符串替換函數,可接受數組或字符做爲參數,而且參數長度不太長,那麼能夠考慮額外寫一段替換代碼,使得每次傳遞參數是一個字符,而不是隻寫一行代碼接受數組做爲查詢和替換的參數。
13
、使用選擇分支語句(譯註:即switch case)好於使用多個ifelse if語句。
14
、用@屏蔽錯誤消息的作法很是低效,極其低效。
15
、打開apachemod_deflate模塊,能夠提升網頁的瀏覽速度。
16
、數據庫鏈接當使用完畢時應關掉,不要用長鏈接。
17
、錯誤消息代價昂貴。
18
、在方法中遞增局部變量,速度是最快的。幾乎與在函數中調用局部變量的速度至關。
19
、遞增一個全局變量要比遞增一個局部變量慢2倍。
20
、遞增一個對象屬性(如:$this->prop++)要比遞增一個局部變量慢3倍。
21
、遞增一個未預約義的局部變量要比遞增一個預約義的局部變量慢910倍。
22
、僅定義一個局部變量而沒在函數中調用它,一樣會減慢速度(其程度至關於遞增一個局部變量)。PHP大概會檢查看是否存在全局變量。
23
、方法調用看來與類中定義的方法的數量無關,由於我(在測試方法以前和以後都)添加了10個方法,但性能上沒有變化。
24
、派生類中的方法運行起來要快於在基類中定義的一樣的方法。
25
、調用帶有一個參數的空函數,其花費的時間至關於執行78次的局部變量遞增操做。相似的方法調用所花費的時間接近於15次的局部變量遞增操做。
26
Apache解析一個PHP腳本的時間要比解析一個靜態HTML頁面慢210倍。儘可能多用靜態HTML頁面,少用腳本。
27
、除非腳本能夠緩存,不然每次調用時都會從新編譯一次。引入一套PHP緩存機制一般能夠提高25%100%的性能,以避免除編譯開銷。
28
、儘可能作緩存,可以使用memcachedmemcached是一款高性能的內存對象緩存系統,可用來加速動態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特有的,並不適用於其餘語言,因此請不要修改你的CJava代碼並期望它們能當即變快,沒用的。++$i更快是由於它只須要3條指令(opcodes)$i++ 則須要4條指令。後置遞增實際上會產生一個臨時變量,這個臨時變量隨後被遞增。而前置遞增直接在原值上遞增。這是最優化處理的一種,正如ZendPHP 優化器所做的那樣。牢記這個優化處理不失爲一個好主意,由於並非全部的指令優化器都會作一樣的優化處理,而且存在大量沒有裝配指令優化器的互聯網服務提供商(ISPs)和服務器。
35
、並非事必面向對象(OOP),面向對象每每開銷很大,每一個方法和對象調用都會消耗不少內存。
36
、並不是要用類實現全部的數據結構,數組也頗有用。
37
、不要把方法細分得過多,仔細想一想你真正打算重用的是哪些代碼?
38
、當你須要時,你總能把代碼分解成方法。
39
、儘可能採用大量的PHP 內置函數。
40
、若是在代碼中存在大量耗時的函數,你能夠考慮用C擴展的方式實現它們。
41
、評估檢驗(profile)你的代碼。檢驗器會告訴你,代碼的哪些部分消耗了多少時間。Xdebug調試器包含了檢驗程序,評估檢驗整體上能夠顯示出代碼的瓶頸。
42
mod_zip可做爲Apache模塊,用來即時壓縮你的數據,並可以讓數據傳輸量下降80%
43
、在能夠用file_get_contents替代filefopenfeoffgets等系列方法的狀況下,儘可能用file_get_contents,由於他的效率高得多!可是要注意file_get_contents在打開一個URL文件時候的PHP版本問題;
44
、儘可能的少進行文件操做,雖然PHP的文件操做效率也不低的;
45
、優化Select SQL語句,在可能的狀況下儘可能少的進行InsertUpdate操做
46
、儘量的使用PHP內部函數(可是我卻爲了找個PHP裏面不存在的函數,浪費了本能夠寫出一個自定義函數的時間,經驗問題啊!);
47
、循環內部不要**變量,尤爲是大變量:對象(這好像不僅是PHP裏面要注意的問題吧?)
48
、多維數組儘可能不要循環嵌套賦值;
49
、在能夠用PHP內部字符串操做函數的狀況下,不要用正則表達式;
50
foreach效率更高,儘可能用foreach代替whilefor循環;
51
、用單引號替代雙引號引用字符串;
52
i+=1代替i=i+1。符合c/c++的習慣,效率還高
53
、對global變量,應該用完就unset()掉;

相關文章
相關標籤/搜索