php-fpm

PS：前段时间配置php-fpm的时候，无意中发现原来它还有两种进程管理方式。与Apache类似，它的进程数也是可以根据设置分为动态和静态的。 php-fpm目前主要又两个分支，分别对应于php-5.2.x的版本和php-5.3.x的版本。在5.2.x的版本中，php-fpm.conf使用的是xml格式，而在新的5.3.x版本中，则是和php.ini一样的配置风格。 在5.2.x版本中，php-fpm.conf中对于进程管理号称是有两种风格，一种是静态(static)的，一种是类似于apache风格(apache-like)的。 Process manager settings <value name=”pm”> Sets style of controling worker process count. Valid values are ’static’ and ‘apache-like’ <value name=”style”>static</value> 按照文档的说明，如果pm的style采用apache-like，启动的进程数应该是和StartServers指定的一样。不过经过数次的尝试，会发现，实际上在这里将pm的style配置成apache-like没有起任何作用。也就是说，这里的apache-like并没有被实现。 不过，在最新的5.3.x的配套php-fpm中

下面是摘自Google讨论话题：《 PHP-FPM on highload tips 》[墙外，翻墙可参考 goagent ]。 When you running a highload website with PHP-FPM via FastCGI, the following tips may be useful to you 如果你的高负载网站使用PHP-FPM管理FastCGI，也许下面这些技巧对你有用 1. Compile PHP's modules as less as possible, the simple the best (fast); 尽量少安装PHP模块，最简单是最好（快）的 2. Increas PHP FastCGI child number to 100 and even more. Sometime, 200 is OK! ( On 4GB memory server); 把你的PHP FastCGI子进程数调到100或以上，在4G内存的服务器上200就可以（建议压力测试来得出自己服务器合理的值） 3. Using SOCKET PHP FastCGI, and put into /dev/shm on Linux; socket连接FastCGI，/dev/shm是内存文件系统，socket放在内存中肯定会快些 4. Increase Linux

mkdir -p ~/mnt/docker/php mkdir -p ~/mnt/docker/php #下载swoole-2.2.0.tgz安装包到software 下载地址：http://pecl.php.net/package/swoole/2.2.0 #创建Dockerfile vim ~/docker/php/Dockerfile #================================Dockerfile================================= FROM daocloud.io/php:7.2-fpm-alpine LABEL maintainer="yjwang088@163.com" COPY ./swoole-2.2.0.tgz /tmp/ WORKDIR /usr/src/swoole # 修改镜像源 RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories # 安装依赖,核心扩展,pecl扩展,git,composer,npm工具 RUN apk update && apk add --no-cache --virtual .build-deps \ $PHPIZE_DEPS \ curl-dev \

LNMP架构介绍目录概要 和LAMP不同的是，提供web服务的是Nginx 并且php是作为一个独立服务存在的，这个服务叫做php-fpm Nginx直接处理静态请求，动态请求会转发给php-fpm LNMP架构 LAMP和LNMP两个架构类似 在LAMP架构中，PHP和Apache是一个整体，php解析是交给Apache来执行的，只不过需要加一个php的模块libphp.so 在LNMP架构中，提供web服务的是Nginx，PHP会启动一个php-fpm服务，Nginx会把用户请求的php交给php-fpm服务去进行处理（用户数据与mysql的交互就是由php-fpm来做的，处理好的结果在高速Nginx，然后通过Nginx告诉用户的浏览器），用户的静态请求将由Nginx直接进行处理（Nginx在处理静态数据的性能上要比Apache快）， Nginx对静态为主的网站，处理用户并发会很大，速度也会快很多 来源： oschina 链接： https://my.oschina.net/u/3707314/blog/1596116

Nginx+php-fpm架构，遇到这个错误时：Request Entity Too Large 或 Nginx 413 Request Entity Too Large，需要做如下调整即可。 1、修改配置一：Tune Nignx.conf setting: # set client body size to 2M under http scope client_max_body_size 2M; 超时设置： send_timeout 60; fastcgi_connect_timeout 300; fastcgi_send_timeout 300; fastcgi_read_timeout 300; 2、修改配置二：Tune php.ini settings: ;This sets the maximum amount of memory in bytes that a script is allowed to allocate memory_limit = 32M ;The maximum size of an uploaded file. upload_max_filesize = 2M ;Sets max size of post data allowed. This setting also affects file upload. To upload large

1.性能优化概述 基于Nginx性能优化，那么在性能优化这一章，我们将分为如下几个方面做介绍 1.首先我们需要了解性能优化要考虑哪些方面。 2.然后我们需要了解性能优化必须要用到的压力测试工具ab。 3.最后我们需要了解系统上有哪些注意和优化的点，以及Nginx配置文件。 我们在做性能优化工作前，我们重点需要考虑哪些方面，和了解哪些方面。 1.首先需要了解我们当前系统结构和瓶颈，了解当前使用的是什么，运行的是什么业务，都有哪些服务，了解每个服务最大能支撑多大并发。比如Nginx作为静态资源服务的并发是多少，最高瓶颈在哪里，能支持多少qps(每秒查询率)的访问请求，那我们怎么得出这组系统结构瓶颈呢，比如top查看系统的cpu负载、内存使用率、总的运行进程等，也可以通过日志去分析请求的情况，当然也可以通过我们前面介绍到的stub_status模块查看当前的连接情况，也可以对线上的业务进行压力测试(低峰期)，去了解当前这套系统能承担多少的请求和并发，已做好相应的评估。这个是我们做性能优化最先考虑的地方。 2.其次我们需要了解业务模式，虽然我们是做性能优化，但每一个性能的优化都是为业务所提供服务的，我们需要了解每个业务接口的类型，比如:电商网站中的抢购模式，这种情况下面，平时没什么流量，但到了抢购时间流量会突增。 我们还需要了解系统层次化的结构，比如: 我们使用Nginx做的是代理

1 CGI （1）什么是CGI： CGI（Common Gateway Interface）公共网关接口， 是WWW技术中最重要的技术之一，有着不可替代的重要地位， CGI是外部应用程序(CGI程序)与Web服务器之间的接口标准，是在CGI程序和Web服务器之间传递消息的规程。CGI规范允许WEB服务器执行外部程序，将他们的输出发送给Web浏览器， CGI将Web的一组简单的超媒体文档变成一个完整的新的交互式媒体。 （2）CGI的目的： CGI是为了保证web server传递过来的数据是标准格式的，方便CGI程序的编写者。 （3）CGI的处理过程： web server （比如nginx）只是内容的分发者。 比如，如果请求/index.html, 那么web server会去文件系统中找到这个文件，发送给浏览器，这里分发的是静态数据。 如果现在请求的是/index.php，根据配置文件，nginx知道这个不是静态文件，需要去找PHP解析器来处理，那么它会把这个请求简单处理后交给PHP解析器。Nginx会传那些数据给（如url，查询字符串，POST数据，HTTP header）PHP解析器呢？CGI就是规定要传哪些数据、以什么样的格式传递给后方处理这个请求的协议。 当web server收到/index.php这个请求后，会启动对应的CGI程序，这里就是PHP的解析器

转自 知乎 的 一个回答 首先，CGI是干嘛的？CGI是为了保证web server传递过来的数据是标准格式的，方便CGI程序的编写者。 web server（比如说nginx）只是内容的分发者。比如，如果请求/index.html，那么web server会去文件系统中找到这个文件，发送给浏览器，这里分发的是静态数据。好了，如果现在请求的是/index.php，根据配置文件，nginx知道这个不是静态文件，需要去找PHP解析器来处理，那么他会把这个请求简单处理后交给PHP解析器。Nginx会传哪些数据给PHP解析器呢？url要有吧，查询字符串也得有吧，POST数据也要有，HTTP header不能少吧，好的，CGI就是规定要传哪些数据、以什么样的格式传递给后方处理这个请求的协议。仔细想想，你在PHP代码中使用的用户从哪里来的。 当web server收到/index.php这个请求后，会启动对应的CGI程序，这里就是PHP的解析器。接下来PHP解析器会解析php.ini文件，初始化执行环境，然后处理请求，再以规定CGI规定的格式返回处理后的结果，退出进程。web server再把结果返回给浏览器。 好了，CGI是个协议，跟进程什么的没关系。那fastcgi又是什么呢？Fastcgi是用来提高CGI程序性能的。 提高性能，那么CGI程序的性能问题在哪呢？"PHP解析器会解析php

CGI CGI全称是“公共网关接口”(Common Gateway Interface)，HTTP服务器与你的或其它机器上的程序进行“交谈”的一种工具，其程序须运行在网络服务器上。 CGI可以用任何一种语言编写，只要这种语言具有标准输入、输出和环境变量。如php,perl,tcl等。 FastCGI FastCGI像是一个常驻(long-live)型的CGI，它可以一直执行着，只要激活后，不会每次都要花费时间去fork一次（这是CGI最为人诟病的fork-and-execute 模式）。它还支持分布式的运算，即 FastCGI 程序可以在网站服务器以外的主机上执行并且接受来自其它网站服务器来的请求。 FastCGI是语言无关的、可伸缩架构的CGI开放扩展，其主要行为是将CGI解释器进程保持在内存中并因此获得较高的性能。众所周知，CGI解释器的反复加载是CGI性能低下的主要原因，如果CGI解释器保持在内存中并接受FastCGI进程管理器调度，则可以提供良好的性能、伸缩性、Fail- Over特性等等。 FastCGI特点 FastCGI具有语言无关性. FastCGI在进程中的应用程序，独立于核心web服务器运行，提供了一个比API更安全的环境。APIs把应用程序的代码与核心的web服务器链接在一起，这意味着在一个错误的API的应用程序可能会损坏其他应用程序或核心服务器。

1、准备工作 docker pull 下载好需要的镜像文件: [root@Docker-Test mysql]# docker pull nginx [root@Docker-Test mysql]# docker pull php:7.1-fpm [root@Docker-Test mysql]# docker pull mysql [root@Docker-Test mysql]# docker pull phpmyadmin/phpmyadmin 2、启动Nginx docker run -d -p 8080:80 --name xj_nginx1 nginx --name　　 自定义容器名称。 -d　　 设置容器在在后台一直运行。 -p　　 端口进行映射，将本地 8080 端口映射到容器内部的 80 端口。 在浏览器中打开 http://IP:8080/，效果如下： 3、启动php-fpm+Nginx容器 为了方便管理，预先创建几个相关的文件目录 mkdir -p /opt/nginx/conf/conf.d && mkdir /opt/nginx/www && mkdir /opt/nginx/logs 解释执行 php 需要 php-fpm，先启动此容器： docker run --name xj_php-fpm -d -v /opt/nginx/www:/var