关于php:使用OPCache提升PHP的性能

38次阅读

共计 2751 个字符,预计需要花费 7 分钟才能阅读完成。

对于 PHP 这样的解释型语言来说,每次的运行都会将所有的代码进行一次加载解析,这样一方面的益处是代码随时都能够进行热更新批改,因为咱们不须要编译。然而这也会带来一个问题,那就是无奈承载过大的访问量。毕竟每次加载解析再开释,都会减少 CPU 的累赘,通常一台 8 核 16G 的服务器在 2、3000 并发左右 CPU 就能达到 60% 以上的使用率。而且如果你应用的是相似于 Laravel 这种大型的框架,效率将更加低下。这个时候,咱们通常会通过减少服务器数量来做负载平衡,从而达到加重服务器压力的成果。不过,这样做的老本又会减少许多。那么,有没有什么优化的计划呢?

鸟哥在他的博客中针对 PHP7 的优化的一篇文章中,第一条倡议就是开启 OPcache。当然,另外一个计划就是应用 Swoole。对于 Swoole 的内容咱们未来再说,明天,咱们先学习学习 OPcache。

什么是 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 的零碎中应用安装包中的文件来进行装置。

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

另外,还须要启用它。

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 的状况。

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

很显著,性能有了很大的进步。不仅速度快了很多,吞吐率也是间接回升了几倍。当然,这只是非常简单的一个测试,不过总体看来,的确对单机的性能晋升有很大的帮忙。最最次要的是,同样的并发状况下,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

===========

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

正文完
 0