一次小故障的追究

实验环境：一台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的资源更为少耗些.