Opcache
- Opcache 原理
PHP作为解释性语言的代表，正常执行流程如下
Request 请求（Nginx,Apache,Cli 等）→ Zend 引擎读取.php 文件 → 扫描其词典和表达式 → 解析文件 → 创建要执行的计算机代码 (称为 Opcode) → 最后执行 Opcode → Response 返回
每一次请求 PHP 脚本都会执行一遍以上步骤，如果 PHP 源代码没有变化，那么 Opcode 也不会变化，显然没有必要每次都重新生成 Opcode，结合在 Web 中无所不在的缓存机制，我们可以把 Opcode 缓存下来，以后直接访问缓存的 Opcode 岂不是更快，启用 Opcode 缓存之后的流程图如下所示：
Opcode cache 的目地是避免重复编译，减少 CPU 和内存开销。
- Opcache 配置
在 PHP配置文件php.ini 下添加：
// 加载opcache(需确认已安装opcache拓展)
zend_extension=opcache.so
// 开启opcache
opcache.enable = 1
// OPcache共享内存存储大小,单位MB
opcache.memory_consumption=1024 // 1G
// PHP使用了一种叫做字符串驻留，默认是4MB
opcache.interned_strings_buffer=32
// 这个选项用于控制内存中最多可以缓存多少个PHP文件,这个选项必须得设置得足够大，大于你的项目中的所有PHP文件的总和
opcache.max_accelerated_files=80000
// 设置缓存的过期时间（单位是秒）,为0的话每次都要检查
opcache.revalidate_freq=3
// 从字面上理解就是“允许更快速关闭”
opcache.fast_shutdown=1
// CLI环境下，PHP启用OPcache
opcache.enable_cli=1
HugePage
- HugePage 原理
通过启用这个特性，PHP7 会把自身的 TEXT 段（执行体）” 挪 “到 Huagepage 上，之前的测试，我们能稳定的在 WordPress 上看到 2%~3% 的 QPS 提升。
关于 Hugepage 是啥，简单的说下就是默认的内存是以 4KB 分页的，而虚拟地址和内存地址是需要转换的， 而这个转换是要查表的，CPU 为了加速这个查表过程都会内建 TLB（Translation Lookaside Buffer）， 显而易见如果虚拟页越小，表里的条目数也就越多，而 TLB 大小是有限的，条目数越多 TLB 的 Cache Miss 也就会越高， 所以如果我们能启用大内存页就能间接降低这个 TLB Cache Miss，至于详细的介绍，Google 一搜一大堆我就不赘述了，这里主要说明下如何启用这个新特性， 从而带来明显的性能提升。 - HugePage 配置
$ sudo sysctl vm.nr_hugepages=512 // 切勿越大越好，会长占内存分配 512 个预留的大页内存:
$ cat /proc/meminfo | grep Huge
AnonHugePages: 106496 kB
HugePages_Total: 512
HugePages_Free: 504
HugePages_Rsvd: 27
HugePages_Surp: 0
Hugepagesize: 2048 kB
然后在 php.ini 中加入:
opcache.huge_code_pages=1 Opcache file cache
- Opcache file cache 介绍
使用 opcache 把编译后的 php 文件存储为文件，实现 php 源码保护和脚本加速，会有很明显的性能提升 - Opcache file cache 配置
在 php.ini 中加入:
opcache.file_cache=/tmp
这样 PHP 就会在 /tmp 目录下 Cache 一些 Opcode 的二进制导出文件，可以跨 PHP 生命周期存在.
配置后需重启 php-fpm
亲测
系统:centOs 7
php 版本：7.4
nginx
laravel: 8.5
优化前
cpu:95%-96%
内存：2G/16G
10 分钟 4W 并发
失败率：24%
聚合报告 每秒处理事务
优化后
cpu:20%-40%
内存：5.8G/16G（此处我 HugePage 设置 2048）
10 分钟 4W 并发
失败率：0%
第一次压测 聚合报告
每秒处理事务
第二次压测
聚合报告
每秒处理事务
