一个master进程,支持多个pool,每个pool由master进程监听不同的端口,pool中有多个worker进程. 
每个worker进程都内置php解释器,并且进程常驻后台,支持prefork动态增加. 
每个worker进程支持在运行时编译脚本并在内存中缓存生成的opcode来提升性能. 
每个worker进程支持配置响应指定请求数后自动重启,master进程会重启挂掉的worker进程. 
每个worker进程能保持一个到mysql/memcached/redis的持久连接,实现连接池,避免重复建立连接,对程序透明. 
使用数据库持久连接时应该设置固定数量的worker进程数,不要使用动态的prefork模式. 
master进程采用epoll模型异步接收和分发请求,listen监听端口,epoll_wait等待连接, 
然后分发给对应pool里的worker进程,worker进程accpet请求后poll处理连接, 
如果worker进程不够用,master进程会prefork更多进程, 
如果prefork达到了pm.max_children上限,worker进程又全都繁忙, 
这时master进程会把请求挂起到连接队列backlog里(默认值是511). 
1个php-fpm工作进程在同一时刻里只能处理1个请求. 
mysql的最大连接数max_connections默认是151. 
只要php-fpm工作进程数不超过151,就不会出现连接不上mysql的情况. 
而且正常情况下,也不需要开启那么多的php-fpm工作进程, 
比如4个php-fpm进程就能跑满4个核心的cpu, 
那么你开40个php-fpm进程也没有任何意义, 
只会占用更多的内存,造成更多的cpu上下文切换,性能反而更差. 
为了减少每个请求都重复建立和释放连接的开销,可以开启持久连接, 
一个php-fpm进程保持一个到mysql的长连接,实现透明的连接池. 
nginx跟php-fpm分开,其实是很好的解耦,php-fpm专门负责处理php请求,一个页面对应一个php请求, 
页面中所有静态资源的请求都由nginx来处理,这样就实现了动静分离,而nginx最擅长的就是处理高并发. 
php-fpm是一个多进程的fastcgi服务,类似apache的prefork的进程模型, 
对于只处理php请求来说,这种模型是很高效很稳定的. 
不像apache(libphp.so),一个页面,要处理多个请求,包括图片,样式表,js脚本,php脚本等. 
php-fpm从5.3开始才进入php源代码主干,之前版本没有php-fpm. 
那时的spawn-fcgi是一个需要调用php-cgi的fastcgi进程管理器, 
另外像apache的mod_fcgid和iis的php manager也需要调用php-cgi进程, 
但php-fpm则根本不依赖php-cgi,完全独立运行,也不依赖php(cli)命令行解释器. 
因为php-fpm是一个内置了php解释器的fastcgi服务,启动时能够自行读取php.ini配置和php-fpm.conf配置. 
个人认为,php-fpm工作进程数,设置为2倍cpu核心数就足够了. 
毕竟,nginx和mysql以及系统同样要消耗cpu. 
根据服务器内存来设置php-fpm进程数非常不合理, 
把内存分配给mysql,memcached,redis,linux磁盘缓存(buffers/cache)这些服务显然更合适. 
过多的php-fpm进程反而会增加cpu上下文切换的开销. 
php代码中应该尽量避免curl或者file_get_contents这些可能会产生较长网络i/o耗时的代码. 
注意设置curlopt_connecttimeout_ms超时时间,避免进程被长时间阻塞. 
如果要异步执行耗时较长的任务,可以 pclose(popen('/path/to/task.php &', 'r')); 打开一个进程来处理, 
或者借助消息队列,总之就是要尽量避免阻塞到php-fpm工作进程. 
在php-fpm.conf中把request_slowlog_timeout设为1秒,在slowlog中查看是否有耗时超过1秒的代码. 
优化代码,能够为所有php-fpm工作进程减负,这个才是提高性能的根本方法. 
能让cpu满负荷运行的操作可以视为cpu密集型操作. 
上传和下载则是典型的i/o密集型操作,因为耗时主要发生在网络i/o和磁盘i/o. 
需要php认证的下载操作可以委托为nginx的aio线程池: 
header(x-accel-redirect: $file_path); 
至于上传操作,比如可以建立一个监听9001端口的名为upload的php-fpm进程池(pool), 
专门负责处理上传操作(通过nginx分发),避免上传操作阻塞到监听9000端口的计算密集的www进程池. 
这时upload进程池多开点进程也无所谓: 
[www] 
listen = 127.0.0.1:9000 
pm = static 
pm.max_children = 4 
[upload] 
listen = 127.0.0.1:9001 
pm = dynamic 
pm.max_children = 8 
pm.start_servers = 4 
pm.min_spare_servers = 4 
pm.max_spare_servers = 4 
利用php-fpm提供的池的隔离性,分离计算密集和i/o密集操作,可以减少阻塞对整个php应用的影响.
文章由开源中国博客eechen原创。
以上就介绍了php fastcgi进程管理器php-fpm的架构，包括了方面的内容，希望对php教程有兴趣的朋友有所帮助。