windows平台上的PHP運行在IIS,Apache,Nginx的效能和速度測試日誌____PHP

測試目的:隱藏

測試目標:只用資料說話,不做評論

測試平台:垃圾伺服器,能更好的看出負載

IIS6.0 win2003 E5300 4G

服務端統一為,就輸出個時間.

<?=time();?>  或者 <%Response.write(now())%>

A. IIS+ISAPI

IIS+PHP5.1.2 fastCGI 背景工作處理序MAX=30 隊列2000

結果:一分鐘執行5400次

B. IIS+FastCGI

結果:一分鐘執行4000次 有卡頓..和500錯誤.不知道為什麼.

修正:我之前配置不當,造成阻塞了...

現在測試為10000次...確實和ASPX單頁面執行效率一模一樣,稍微有1%的額外開銷.

C.IIS+ASPX

一分鐘執行:9600次

D.upupw( nginx + PHP-cgi)  壓力測試通不過 4800左右伴隨500錯誤

修正:預設的fastCGI設定存在效能問題,暴力請求會造成500錯誤

E.UniServer Zero XI (Apache+PHP)穩定...9800次..出乎意料呢

不知道咋回事只要php跑在CGI模式下,壓力一上去就有500錯誤,調了fastcgi_ext.ini也沒用..怪...

不過目前看出一個問題,就是只要是windows,極限頂天也就10000次每分鐘..(E5300垃圾CPU)

[Types]
php=PHP
htm:1916250451=PHP   //讓IIS裡面的某一個網站(網站數字ID見IIS)控制讓html也作為php發送給cgi來解析
html:1916250451=PHP


[PHP]
ExePath=C:\PHP\php-cgi.exe
MaxInstances=300
InstanceMaxRequests=20000
queueLength=2000
IdleTimeout=300   //當沒有任何串連請求,多久時間關閉進程(單位:秒)
EnvironmentVars=PHP_FCGI_MAX_REQUESTS:20000,PHPRC:C:\PHP\
;ActivityTimeout=600
;RequestTimeout=600  

;紅色字型部分數字要統一

;關於queueLegth,這個是是指master進程的隊列長度,根據網站訪問量應該合理調整.也是主要調整參數.調低了,比如10個,你一直按著F5重新整理,很快就會提示你500錯誤即不再接收新串連,因為隊列滿了,前面的10個還沒處理完,直接就拋出用戶端500提示了,丟棄了.隊列處理完再接收新的連結請求.所以如果這個時候你看下伺服器的CPU,沒有超過87%的時候,可以調高哈,當然這個是受到整個後台系統的影響的.在一條完成的後台服務體系中,最薄弱的環節是可以測試出來的,慢慢增加queueLength,從100開始,間隔200一加,慢慢增加,當F5一直按著,CPU不再升高,然後一放開,很快就頁面就顯示出來了,說明隊列處理完了.放開F5到頁面顯示出來,這中間的這個時間差,如果你覺得達到理想狀態了,那麼這個時候的queueLength就是最佳值.  queueLength太低,會造成CPU還沒有滿負荷但是頻繁出現500錯誤,拒絕再接收新串連;如果值太高,那麼會一直阻塞很久,頁面才顯示出來...最長時間是PHP.ini設定的逾時時間(預設30秒)...所以怎麼均衡這個使用者體驗時間,就是個技巧了,和技術無關.大家自己試試吧.

另外解釋下啊,最大請求20000次是指單進程到2W次就重啟進程一下.會佔用開銷.但是不大.

但是因為cgi獨特的非同步響應機制所以可以由master進程並發下發子請求給slave進程,所以這種非同步模型可以平行處理很多請求....適用於高負荷網站...如果考慮到被駭客DDOS了,那麼也可以用fastCGI臨時頂一下...那麼如果是我被攻擊了,我是不會這麼做的,因為IIS上幾千/秒 的極限負載對於DDOS來說本來就意義不大. 正確的做法是遇到DDOS就上(硬防+fastCGI)或者封IP(需要輔助程式來識別並自動封,手動封那麼多IP,不現實)

普通的小型網站,PV5W以下都建議採用ISAPI方式,可靠,穩定,沒有效能問題.

高負荷網站,絕對要用fastCGI模型.以便通過非同步進程通訊模型,充分利用多核心CPU來非同步處理更多的請求.這是用好多核CPU的手法.

最終我的配置,感覺平衡的還不錯~~~

[Types]
php=PHP
htm:1916250451=PHP
html:1916250451=PHP 


[PHP]
ExePath=C:\PHP\php-cgi.exe
MaxInstances=8
InstanceMaxRequests=20000
queueLength=2000
IdleTimeout=300 
EnvironmentVars=PHP_FCGI_MAX_REQUESTS:20000,PHPRC:C:\PHP\
ActivityTimeout=300
RequestTimeout=300

當然生產伺服器是E5 2630v2雙路 24核心 所以上面我調的8進程2W請求這麼個等級 爽飛! 極限請求次數沒測過,反正目前完全沒問題,可抗住DDOS...嘎嘎...

InstanceMaxRequests 用來設定應用程式集區回收。FastCGI進程請求數達到InstanceMaxRequests數值20000，應用程式集區將自動回收。預設值是1000。 當環境變數PHP_FCGI_MAX_REQUESTS達到20000將自動回收應用程式集區。 RequestTimeout 佈建要求逾時時間，也就是請求允許的最大時間，如果FastCGI進程請求超過此設定將被禁止，值是90秒。 ActivityTimeout 指定FastCGI進程請求的最大活躍時間，在設定時間內，FastCGI進程和IIS沒有通訊，將終止進程。預設值是70秒。

用windows主要是方便,安全性也可以做的不錯

用linux是強悍,但是不太方便啊,權衡了下.別人下班了,你可能還在搞vi..算了,裝windows...哈哈

-----------------------------第二天的分割線-----------------------------

今天想罵人,因為剛才才發現昨天測試的資料都不準確.

忽略了網卡流量已經滿載了.

因為我用的是wifi,2.4g150M的極限速度也就是4MB/S左右...完全不夠測試流量啊.!!!!

今天重新測試:

Kangle+FastCGI   實測1800次/10秒 還是基於IOCP模型的...無語了

IIS+FastCGI 請求 3700次/10秒

IIS+ASPX 3800次/10秒

UniServer Zero XI (Apache+PHP)穩定...3800次/10秒

IIS+PHP(ISAPI) 2000次/10秒

IIS+一個txt檔案 3800次/10秒(說明是E8200這種CPU+ICH7南橋晶片集的極限吧)

至此,塵埃落定....nginx沒測,實際上都是fastCGI模型架構,標準非同步socket模型,效能應該和UniServer Zero XI差不多,,(高一點點吧,算4000咯,哈哈)