关于php:Chapter-13一次性能测试和优化过程

欢送来到「我是真的狗杂谈世界」，关注不迷路

背景

最近一个我的项目上线前 QA 对压测后果不是很称心（并且示意之前的我的项目压测后果也都不现实），于是我在上线后（上线前是必定来不及了）开始了一轮性能测试、排查和优化，记录一下整个过程。

思考过程

根底信息

QA 同学提供的压测环境与论断：

• 施压侧：

  • 并发度 100～300；
  • 继续运行 120～300 秒；

• 被压侧：

  • 单正本资源 1C2G；
  • 正本数 1～4；

• 后果体现：

  • CPU：单正本 100%（但有时呈现某正本 100%，其余正本 60～80% 左右）；
  • 内存：单正本 15～20%（但有时呈现某正本高至 50%）
  • QPS：单正本 100～120；
  • 响应耗时：Avg(487～596ms)；50TH(19～27ms)；90TH(1867～3099ms)；95TH(2409～3902ms)；99TH(4460～7002ms)；MAX(8589～13298ms)；

外围问题

对于性能、压测等相干概念可参考「Foundation 11. 性能是什么」

• QPS 体现较低；
• CPU 占用过高，很快被打满；
• 响应耗时存在大量（90TH 以上）过高；

以后这三者是有关联的，以后看来单个申请对于 CPU 资源需要较高，导致在小并发下 CPU 资源已占满；
随着并发度增高，零碎通过频繁调度来调配 CPU 资源，调度磨损减少（用于解决业务逻辑的比例升高）；
因而 CPU 占用过高也会肯定水平连累响应耗时、QPS 体现。

狐疑方向

• 硬件性能：之前有发现压测环境后果较比生产环境低，且两侧环境为独立的集群，因而狐疑两侧集群节点自身硬件性能差别较大；
• 执行过程：因为是 PHP FPM 模式下运行的服务，FastCGI 处理过程、PHP 代码解释执行过程等都可能造成 CPU 资源的占用、耗时；
• IO 阻塞度：业务逻辑中简单（屡次）同步阻塞申请（三方 HTTP 接口、MySQL、Redis）较比简略（少次）会造成申请响应须要工夫变长，升高 QPS；
• 短连资源：整个服务对三方 HTTP 接口、MySQL、Redis 都采纳的短连，连贯仅在申请周期内复用，申请完结后开释，对于连贯的频繁创立销毁也会占用 CPU 资源、耗时；
• 框架磨损：新版开发框架投入使用后没有太关注性能磨损问题，实践上这块肯定会存在磨损，只是水平和要害磨损点问题。

排查办法

（尽量）管制其余变量放弃雷同的状况下，针对要排查的环节、对象进行多组压测比照，记录并剖析得出结论。

实际与论断

定位基准

因为 QA 提供的论断看起来存在很多不稳定性，因而我决定在压测环境上基于该我的项目先进行一波测试，作为后续比照、剖析、钻研等排查工作的基准。

第一波测试

从第一波测试记录数据（因为 QPS 体现已产生过于不稳固景象了，其余数据就临时没有关注和记录）很容易发现，除了我管制住的变量外，肯定还存在一个我没发现的变量影响了压测体现；
而这两次测试存在的变量只有两个：

• 测试工夫：因为压测服务做了串行管制（同一个工夫点只能最多一个压测工作执行），上述两波测试是在不同的工夫点进行的。
• 被测正本：因为压测环境须要很多配置老本，没有别离配置两套压测环境，上述两波测试之间进行了利用正本重建（从新构建了服务）。

为了进一步排查上述两个变量，我每次屡次重建正本，每次重建正本后进行相隔一段时间的多组压测，景象如下：

• 雷同正本（不重建正本）中的体现是稳固的（如果是 500 高低则始终是 500 高低，如果是 1000 高低则始终是 1000 高低），甚至到第二天仍旧是稳固的；
• 不同正本（重建正本）时的体现会产生稳定（比方 500 变成 1000，1000 变 500），但也不是每次重建都必然产生稳定切换。

基于上述景象，根本能够排除工夫差别，而狐疑正本调度到的节点的硬件或其余基础设施的差别导致；
我将此问题报告给服务器基础设施团队后帮助排查定位，最终发现压测环境 4 个节点其中 1 个节点的 CPU 基频在 1.5～3.5GHz 之间动静稳定（失常 4 个节点都应该是 3.5GHz）；

在他们解决问题的同时，我管他们要了一个独立节点来持续我的测试，前面所有资源将依照下述形容：

• 新节点：代表管他们要来的独立节点，性能自身很差，2C 体现还不如原节点 1C 好；
• 原节点：代表除 CPU 异样节点之外的压测环境节点（实践上与生产环境节点性能仍有差距）；
• X 号正本：代表正本重建，雷同的 X 代表正本未通过重建；原节点有意义（因为压测环境节点仍旧会有一些轻微差别），新节点无意义（就只有一个节点）；
• 健康检查：代表业务上一个接口间接返回，没有业务逻辑和三方申请；
• 简略逻辑：代表业务上一个接口蕴含一个 MySQL 查问；
• 简略逻辑 *x：代表业务上一个接口蕴含 x 个雷同的 MySQL 查问；
• 简单逻辑：代表该我的项目业务实在逻辑（一个接口蕴含 2～8 次 MySQL、Redis、HTTP 接口申请等）；

持续测试

• 新节点在并发 1～5 之间达到 CPU100%，QPS 最高体现也在这之间达到（实践上会略高于 526），体现的确很拉垮。。。
• 原节点在并发 1～5 之间达到 CPU100%，QPS 最高体现也在这之间达到（实践上会略高于 660/624）。
• CPU 未打满时，随着并发度提高，QPS、CPU 占用率也随之增长，响应耗时保持稳定；
• CPU 打满后，随着并发度提高，QPS 先稳固后逐渐升高，响应耗时逐渐增大。

PHP8&Jit

• PHP8.0 较比 7.4 在业务代码不动的状况下（基于 7.4 及之前语法）没有间接的性能晋升；
• CPU 耗费大头不在 opcache 转 machine code 环节（想想也是）；
• PHP8.0+Jit 目前无奈带来并发和性能体现的晋升。

IO 梗塞次数

• 逻辑中不同水平的 IO 会导致单次申请的响应耗时减少，但对 CPU 的占用率影响较小；
• 申请响应耗时高阻塞 IO 较比低阻塞 IO 广泛减少；
• 并发度未将 CPU 打满时，高阻塞 IO 较比低阻塞 IO 的 QPS 体现要低；
• 当并发度晋升将 CPU 打满后，高阻塞 IO 较比低阻塞 IO 的 QPS 体现简直统一

PDO 长连贯

网络连接资源复用较比不复用在以后业务特点下能带来：

• 晋升 35～55%QPS；
• 升高 25～37% 响应耗时。

框架截断

磨损次要产生环节：

• 引入主动加载（composer autoload）；
• 加载我的项目配置；
• 加载底层配置。

优化方向

短连改长连

将申请 MySQL、Redis 的连贯模式改成长连贯，将连贯周期由申请级别延长至 FPM 过程级别，以此缩小连贯创立销毁操作升高 CPU 占用、缩小响应耗时晋升性能整体体现。

但思考到：

• MySQL、Redis 连接数将简直与 FPM 开启的 Work 过程数量统一；
• 多我的项目、多组共用 MySQL、Redis；
• 短连模式下，QPS 过高反而会带来本地端口用尽的问题（具体见本文最初）。

决定临时不采纳此计划。

缓存我的项目与底层配置

将原先每次申请都读取多个 ini 配置文件并解析构造革新成初始化时读取并解析而后回写为 php 数组文件：

• 防止 config map 的性能影响（原先这些 ini 配置都是通过 config map 挂载进我的项目）；
• 节俭 ini 配置解析老本（php 文件间接借用 php 自身 opcache、jit 优化就足够）。

我将这个优化做到了新框架的后续版本中，并且压测验证：

缓存配置较比不缓存对没有连贯和阻塞 IO 的逻辑能带来：

• 晋升 46～121%QPS；
• 升高 34~54% 响应耗时；
• 并发度越高，成果越显著（在可接受的并发度范畴内）。

我也对带上不同水平业务逻辑的场景进行了测试；

简略逻辑下缓存配置较比不缓存能带来：

• 晋升 9～14%QPS；
• 升高 9~12% 响应耗时；

简单逻辑下缓存配置较比不缓存能带来：

• 晋升 4～17%QPS；
• 升高 5~14% 响应耗时；

换运行模式

如果后面两者都不可用或者不能满足需要的时候，能够思考更换以后这种 FPM 的运行模式，改用 Cli+ 异步模型：

• 天生能够应用 MySQL、Redis、HTTP 等连接池技术，又不须要当心连接数过多的问题；
• 进一步缩小代码解释执行过程的耗费，Opcache 和 Jit 技术能够进一步发挥作用；
• 异步搭配 yield/Fiber，或是 swoole 封装的异步库充分利用 CPU，晋升单接口响应效率。

但这样无疑是存在较高的老本和危险的：

• 现有的框架、库包都是基于同步阻塞封装的，异步可能带来并发争竞隐患；
• FPM 同步阻塞模型就义肯定性能带来的是开发效率和门槛的劣势，如果换成异步模型，对开发人员和业务无疑会带来更高的门槛和危险；
• 相似 swoole+ 异步协程其实简直都相当于换了大半个语言了。

整体论断

• 目前 1C2G 在压测环境个别的逻辑都能够达到 250 甚至更高了，临时满足咱们的业务需要（更高的性能体现能够通过扩大副原本实现）；
• 还有很多的优化计划和空间，但思考到团队目前的状况和计划的老本与危险，临时不发展这类计划。

短连单正本 QPS 过高的问题

以后的零碎设置为：

• 本地可用客户端端口范畴：32768~60999
• time wait 状态疾速回收和重用：没有权限，但依据景象察看应该是 60s

当我调大 CPU 资源为 2C 压测一个简略逻辑（每个申请会创立一个 MySQL 连贯，申请完结就被动 close 连贯）时，QPS 达到 500 高低，但最初几秒会呈现本地端口用尽的问题。