使用OPCache提高PHP的性能

对于 PHP 这样的解释型语言来讲,每次的运行都会将全部的代码进行一次加载解析,这样一方面的好处是代码随时均可以进行热更新修改,由于咱们不须要编译。可是这也会带来一个问题,那就是没法承载过大的访问量。毕竟每次加载解析再释放,都会增长 CPU 的负担,一般一台 8核16G 的服务器在二、3000并发左右 CPU 就能达到60%以上的使用率。并且若是你使用的是相似于 Laravel 这种大型的框架,效率将更加低下。这个时候,咱们一般会经过增长服务器数量来作负载均衡,从而达到减轻服务器压力的效果。不过,这样作的成本又会增长许多。那么,有没有什么优化的方案呢?php

鸟哥在他的博客中针对 PHP7 的优化的一篇文章中,第一条建议就是开启 OPcache 。固然,另一个方案就是使用 Swoole 。关于 Swoole 的内容咱们未来再说,今天,咱们先学习学习 OPcache 。html

什么是 OPcache

OPcache 经过将 PHP 脚本预编译的字节码存储到共享内存中来提高 PHP 的性能, 存储预编译字节码的好处就是 省去了每次加载和解析 PHP 脚本的开销。缓存

这是 PHP 文档中关于 OPcache 的简介,也就是说,OPcache 节约了每次加载和解析的步骤,将第一次解析编译后的脚本字节码缓存到系统的共享内存中。其实,这就相似于一个不彻底的编译。服务器

相似于 Java 之类的语言,都是要打包编译以后才能上线运行的,好比打包成一个 jar包 。C++ 或 C# 能够打包成一个 .dll 或 .exe 。这些打包以后的文件就是编译完成的文件,将它们运行起来后通常会一直保持运行状态,也就是会成为一个常驻进程,它们的代码就进入内存中了。在程序运行的时候,不须要再进行解释或编译,天然速度就要快不少。而 OPcache 也是起到相似的做用。只不过它并非彻底的一套编译流程,咱们仍是依赖的 PHP-FPM 来运行脚本,只不过在开启 OPcache 后,PHP-FPM 会先从内存中查找是否已经有相关的已经缓存的字节码在内存中了,若是有的话就直接取用,若是没有的话,会再次进行解释编译后缓存下来。另外,OPcache 是针对文件的,也就是说,一个文件若是是新增长进来的,只有运行过它才会缓存,若是没有运行过,它并不在当前的共享内存中。并发

安装 Opcache

OPcache 已是 PHP 的官方扩展并随安装包一块儿发布了,因此,咱们能够在编译安装 PHP 时使用 --enable-opcache 来开启扩展,它已是默认扩展。也能够在未安装 OPcache 的系统中使用安装包中的文件来进行安装。mvc

cd php-7.4.4/ext/opcache/
phpize
./configure
make && make install

须要注意的是, OPcache 和 Xdebug 在生产环境中尽可能不要一块儿使用。自己 Xdebug 就是不推荐在生产环境中使用的,若是必定须要同时使用的话,须要先加载 OPcache ,而后再加载 Xdebug 。负载均衡

扩展安装后,在 php.ini 文件中打开扩展。须要注意的是,OPcache 扩展是 Zend 扩展包,因此咱们须要打开的是 Zend 扩展。框架

zend_extension=opcache.so

另外,还须要启用它。php-fpm

opcache.enable=1

当开启了 OPcache 以后,咱们再更新代码将会发现刚刚更新的代码不是咱们最新的代码。这是由于代码已经被缓存了,就像 Java 同样,咱们须要重启服务才行。那么 PHP 这边重启的是什么呢?固然就是重启下咱们的 PHP-FPM 就能够了,直接使用 kill -USR2 命令去重启主进程就好了。这里也给出一个快速重启的命令。性能

ps -ef | grep "php-fpm: master" | grep -v grep | cut -c 9-15 | xargs kill -USR2
感谢知乎大佬的指正,重启 PHP-FPM 不是最佳方案,应该使用 opcache_reset() 手动重启,或者经过 php.ini 文件的配置 opcache.validate_timestamps + opcache.revalidate_freq 自动间隔编译,或者经过 opcache_compile_file() 来直接从新编译修改过的文件

ab 测试效果

咱们进行测试的内容是测试环境的一台2核4G的服务器,使用的 PHP 版本是 PHP7.4 ,正常的 Nginx 及 PHP 配置, ulimit 也都开到了最大。代码只是简单的输出了一行文字,不过咱们使用的是一个简单的 mvc 框架 ,也就是说这段代码运行起来至少也会加载几个文件,而不是简简单单的一个文件。

首先咱们来看未开启 OPcache 的状况。

/img/bVcRAsw

接下来是开启了 OPcache 的状况。

/img/bVcRAsx

很明显,性能有了很大的提升。不只速度快了不少,吞吐率也是直接上升了几倍。固然,这只是很是简单的一个测试,不过整体看来,确实对单机的性能提高有很大的帮助。最最主要的是,一样的并发状况下,CPU 资源也比未开启的状态下低了70%。

配置参考

在 PHP 的官方文档中,已经为咱们给出了一套默认的 OPcache 在 php.ini 中的配置。通过测试,基本没什么问题,固然,如今尚未在生产环境中使用过,还须要进行更多的测试。不过文档中指出,这套配置是能够直接运用到线上的,不过须要注意的是某些使用了注解之类功能的高级框架可能须要注意某些参数。

opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1

具体的配置说明以及其余的一些配置选项咱们能够参考官方文档进行详细的了解。

总结

既然是咱们的 PHP 大神鸟哥推荐的,并且也是官方推荐的扩展,我以为在正式生产环境中使用不会有太大问题。另外,官方也给出了一套能够直接运用于线上生产环境的配置参数,也方便咱们直接在线上进行测试。目前在生产环境中,咱们只使用了一台服务器来进行测试,而且给它多分配了一些负载过来,从目前的状况来看,这一台机器的运行效率比其余几台的高不少。由于它一方面处理了更多的请求,另外一方面它的 CPU 资源占用率尚未其余几台机器高。同时,OPcache 也不须要咱们去了解更多的进程协程之类的知识,不像 Swoole 同样的会带来更高的学习成本。因此综上所述,在测试完备的状况下,OPcache 绝对是咱们最优先考虑的单机优化方案。

参考文档:
https://www.laruence.com/2015/12/04/3086.html
https://www.php.net/manual/zh/book.opcache.php

===========

各自媒体平台都可搜索【硬核项目经理】

相关文章
相关标签/搜索