PHP-FPM

PHP-FPM

先说一下PHP-FPM的进程模型,PHP-FPM采用的是Master/Worker进程模型。当PHP-FPM启动时,会读取配置文件,然后创建一个Master进程和若干个Worker进程(具体是几个Worker进程是由php-fpm.conf中配置的个数决定)。Worker进程是由Master进程fork出来的。

Master进程和Worker进程的作用

  • Master进程:负责管理Worker进程、监听端口
  • Worker进程:处理业务逻辑

PHP-FPM进程管理方式

PHP-FPM进程管理方式有动态(Dynamic)、静态(Static)、按需(Ondemand)三种

动态(Dynamic) 在这种方式下,PHP-FPM启动时会创建一定数量的Worker进程。当请求数逐渐增大时,会动态增加Worker进程的数量;当请求数降下来时,会销毁刚才动态创建出来的Worker进程。在这种方式下,如果配置的最大进程数过大,当请求量增加时会出现大量Worker进程,进程之间会频繁切换,浪费大量CPU资源。

配置Worker进程的数量:

  • pm.start_servers:动态方式下的起始php-fpm进程数量。
  • pm.min_spare_servers:动态方式下的最小php-fpm进程数量。
  • pm.max_spare_servers:动态方式下的最大php-fpm进程数量。

静态(Static) 这种方式下,PHP-FPM启动时会创建配置文件中指定数量的Worker进程,不会根据请求数量的多少而增加减少。因为PHP-FPM开启的每个Worker进程同一时间只能处理一个请求,所以在这种方式下当请求增大的时候,将会出现等待的情形。但在用户请求波动大的时候,对 Linux 操作系统进程的处理上耗费的系统资源低。

下面的参数可以配置Worker进程的数量: pm.max_children:静态方式下开启的php-fpm进程数量。

按需(Ondemand) 在这种方式下,PHP-FPM启动时,不会创建Worker进程,当请求到达的时候Master进程才会fork出子进程。在这种模式下,如果请求量比较大,Master进程会非常繁忙,会占用大量CPU时间。所以这种模式不适合大流量的环境。

总结

通常来说,对于比较大内存的服务器,设置为静态的话会提高效率。因为频繁开关 php-fpm 进程也会有时滞,所以内存够大的情况下开静态效果会更好。数量也可以根据 内存/30M 得到。比如说 2GB 内存的服务器,可以设置为 50;4GB 内存可以设置为 100 等。高配机器选静态,低配机器(省内存)选动态,高配机器用动态不能充分利用内存资源和 CPU 资源,也无法及时应对瞬时高并发。

在Nginx+PHP-FPM的架构中, 当用户请求一个http地址时,Nginx会收到请求,然后将请求转发给PHP-FPM,PHP-FPM收到请求后会将请求转发给一个空闲的Worker进程。当Worker进程处理完后会将结果返回给Nginx,Ngixn再讲内容返回给用户。

PHP-FPM 的进程管理方式和 Nginx 的进程管理方式有些类似。在处理请求时,并非由主进程接受请求后转给子进程,而是子进程「抢占式」地接受用户请求。本质上 PHP-FPM 多进程以及 Nginx 多进程,都是在主进程监听同一个端口后,Fork 子进程达到多个进程监听同一端口的目的。

优化性能

首先,我们应该思考导致性能差可能的原因是什么。如果一个应用的性能差,我们往往会从 2 个方面来分析,一个是 IO 性能,一个是计算性能。

I/O 方面,因为 PHP-FPM 模式下难以做连接池,所以高并发业务下的网络处理会有劣势。注意我这里一直说的都是 PHP-FPM 模式下,在 CLI 模式下还是可以自己做连接池的。只不过这个连接池仅限于 CLI 模式的单进程内,而且这个模式不能用于处理网络请求(比如 HTTP 请求)。因为 PHP 默认单进程模式,FPM、CLI 都是默认单进程,即便 CLI 可以做连接池 ,也不方便做链接保活(不能同时做心跳检测)。

计算性能上来说,虽然 PHP 是用 C 写的,如果单纯论计算性能是不错的。但问题在于 PHP 处理请求时,每次都要解析 PHP 脚本、翻译 PHP 代码为 Opcode、用 Zend 虚拟机执行 Opcode,处理结束,释放资源。经历这样的过程 是导致 PHP 计算性能慢的最大原因之一。

如何优化:

  • 对于计算性能来说,使用 Zend OPcache 扩展,缓存字节码。
  • 对于I/O 性能来说,使用文件 cache 或者 memcached 减轻对网络 Cache 的压力;使用 Yac 减轻对 Cache 层的压力;在同一次请求中;复用链接不要每次都用新的;合理设计日志组件类库,优化 Logger 减少对文件操作的次数来减少 IO 的压力。
  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
这个错误表明在尝试启动 PHP-FPM (FastCGI Process Manager) 服务时遇到了问题,因为系统找不到名为 `php-fpm.service` 的单位。这通常意味着以下几个可能的情况: 1. **服务未安装**:可能是 PHPPHP-FPM 服务尚未在您的系统上正确安装或配置。请确认您已经安装了 PHP,并且 PHP-FPM 包也在相应的包管理器(如 apt、yum 或 dnf)中。 2. **服务配置文件缺失**:检查 `/etc/systemd/system` 或 `/etc/systemd/system.d` 目录下的 `php-fpm.service` 或 `.service.d` 文件是否存在。如果文件不存在,说明可能没有创建默认的服务定义。 3. **服务未启用**:即使服务文件存在,也可能是服务没有被系统自动启用。运行 `systemctl status php-fpm` 或 `systemctl list-unit-files | grep php-fpm` 来查看服务是否已经启用。 4. **权限问题**:确保您有权限执行 `systemctl` 命令来启动服务。如果不是 root 用户,可能需要使用 `sudo`。 为了解决这个问题,请按照以下步骤操作: 1. **确认安装**:运行 `php -v` 和 `php-fpm --version` 确定 PHPPHP-FPM 是否已安装。 2. **检查服务文件**:检查上述目录下是否有 `php-fpm.service` 或相关配置文件。 3. **启用服务**:使用 `systemctl enable php-fpm` 设置服务为开机启动。 4. **启动服务**:尝试 `systemctl start php-fpm` 或 `sudo systemctl start php-fpm`。 5. **查看日志**:如果启动失败,查看 `/var/log/php-fpm.log` 或 `/var/log/syslog` 中的错误信息,可能能获取更详细的错误原因。 6. **更新或重新安装**:如果问题依然存在,考虑更新或重新安装 PHPPHP-FPM

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值