PHP是一种解释性的脚本语言，程序是边编译边执行，编译和执行都需要使用资源、花费时间。

在大规模的并发环境下，每一个请求都需要编译，那必将会浪费大量的CPU时间片。

举个例子

一个接口有1W的并发，程序代码在短时间并不会改变，这1W个请求每次都需要执行编译操作，浪费的时间为：

1W * 编译时间

假设编译时间为 10ms，那么1秒内浪费的编译时间为：100s。这100s干点啥不好，哈哈哈。

正文

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

php不开启OPcache时请求的流程图

不开启OPcache请求执行流程

php开启OPcache时请求的流程图

开启OPcache请求执行流程

对比以上两个流程，发现开启了OPcache，程序减少了IO获取文件、编译的流程。程序的性能自然就得到了提升。

开启opche的优点减少了程序读取文件的时间，也就是对磁盘IO的操作。磁盘IO是毫秒级别，内存IO是纳秒级别，内存的处理读写速度是磁盘的10W倍，大家可自行体会其中的性能差异。减少了程序编译的时间，编译程序本身就比较消耗CPU。减少了读取文件、编译本身也就释放了CPU，减少了CPU的上下文切换。

开启OPcache的缺点

中间码放在内存中，占用了一些内存，不过现在内存的造价并不像以前高昂，一块内存对于普通人来说都不是什么大的开销。

OPcache是将中间码存储在共享内存中，更新中间码有点麻烦。

更新中间码方式

通过配置文件

opcache.validate_timestamps=true 并且 opcache.revalidate_freq=0 时是每次请求都会检查脚本是否更新（不建议这么做）；opcache.revalidate_freq !=0 时每隔配置的秒数做一次检查。

opcache.validate_timestamps=false 时 opcache.revalidate_freq 不生效，程序只有通过 opcache_reset() 或 opcache_invalidate() 来手动重置 OPcache。

重启/重载

重启php-fpm

会造成请求中断。

重新载入php-fpm

reload 首先会向子进程发送一个 SIGQUIT 信号，并注册一个定时器， 如果没有规定时间推出的子进程，接着会收到一个 SIGTERM 信号，如果一秒还没有推出，就会收到一个 SIGKILL 信号，强制杀死。这里也可能会造成请求的中断。

手动调用

手动调用 opcache_reset()、opcache_invalidate()

个人比较推荐通过手动调用的方式去更新中间码，开发人员可以开发一个更新OPcache接口，这个接口的安全性要求要比较高，主要作用是调用 opcache_reset() 函数。当运维人员部署代码完成后，运维人员登陆后台管理系统，点击部署按钮，发送一个更新 OPcache 的请求给所有的负载均衡下的机器，这样就可以完成程序的整体更新了。