一次小故障的追究

實驗環境：一臺Ubuntu（10.230.69.40）  一臺 CentOS release 5.5（10.230.69.40） 所有安裝lnmp環境。

啓動 Ubuntu ，查看nginx

咱們看到nginx有一個主進程和一個work進程，work進程數目通常等於等於cpu個數，再看一下php

php-fpm採用epool異步機制，咱們經過修改來限制php進程的數目，來模擬高併發php進程阻塞的狀況,nginx採用epoll的異步請求-喚醒機制,不單單在程序和操做系統之間實現了異步,在網絡I/O和硬盤I/O方面也實現了非阻塞.

經過修改pm.max_children,pm.start_servers，pm.min_spare_servers，pm.max_spare_servers參數來控制php進程數目，是否是和Apache的處理http的請求有點類似,預派生型的,php也支持 靜態模式的配置方式.

重啓php-fpm ,咱們來看一下php進程的個數 

咱們增長一個請求,

再增長一個請求進來

能夠看到php的進程已經在排隊了。順便說一句,nginx在接受系統傳過來的請求時,會發生多個work進程爭奪請求的驚鴻效應,每個獨立的請求,只能有一個work進程來處理,nginx採用共享鎖解決了這個問題。可是php仍是會出現阻塞.這時咱們經過另一個服務器上的程序來訪問這個機器的程序接口,因爲這個機器的php進程已經處於阻塞狀態,可能會出現超時狀態.

咱們用傳統的file_get_contents（）請求方式來請求,觀察下資源消耗:

27539 www       25   0  249m  24m 6488 R 100.1  0.3   0:11.57  能夠看到cpu和內存消耗是很是高的。

strace -p 看看

換一種寫法試試看：

$ch = curl_init($url) ;  
curl_setopt($ch, CURLOPT_TIMEOUT,10);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true) ; // 獲取數據返回  
curl_setopt($ch, CURLOPT_BINARYTRANSFER, true) ; // 在啓用 CURLOPT_RETURNTRANSFER 時候將獲取數據返回  
$data = curl_exec($ch) ; 

top看不到特別耗時的php進程,測試效果也是這樣的.因而可知,curl的資源更爲少耗些.