乐趣区

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

jiezi

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

背景

最近一个我的项目上线前 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 AVG 50TH 90TH 95TH 99TH MAX CPU（峰值）
2C2G PHP-FPM7.4+OPcache 新框架 + 健康检查 2 980 – – – – – – 80
2C2G PHP-FPM7.4+OPcache 新框架 + 健康检查 2 490 – – – – – – 90

从第一波测试记录数据（因为 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 接口申请等）；

持续测试

资源状况 程序状况 接口复杂度 并发度 QPS AVG 50TH 90TH 95TH 99TH MAX CPU（峰值）
2C2G；新节点；0 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 1 162 5.63 6 6 6 8 20 31
1C2G；原节点；1 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 1 496 1.63 2 2 2 2 217 80
1C2G；原节点；2 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 1 484 1.67 2 2 2 3 138 73
2C2G；新节点；0 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 5 526 8.66 6 7 40 47 1686 100
1C2G；原节点；1 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 5 660 6.43 2 2 72 77 2300 100
1C2G；原节点；2 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 5 624 6.9 2 3 73 78 900 100
2C2G；新节点；0 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 20 462 41.74 7 93 93 95 1858 100
1C2G；原节点；1 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 20 530 36.32 3 96 96 97 2402 100
1C2G；原节点；2 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 20 509 38.11 3 96 97 98 1715 100
2C2G；新节点；0 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 50 371 129.5 102 200 203 298 2023 100
1C2G；原节点；1 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 50 472 104.12 100 195 197 202 3056 100
1C2G；原节点；2 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 50 446 110.3 100 197 199 297 1827 94
  • 新节点在并发 1～5 之间达到 CPU100%，QPS 最高体现也在这之间达到（实践上会略高于 526），体现的确很拉垮。。。
  • 原节点在并发 1～5 之间达到 CPU100%，QPS 最高体现也在这之间达到（实践上会略高于 660/624）。
  • CPU 未打满时，随着并发度提高，QPS、CPU 占用率也随之增长，响应耗时保持稳定；
  • CPU 打满后，随着并发度提高，QPS 先稳固后逐渐升高，响应耗时逐渐增大。

PHP8&Jit

资源状况 程序状况 接口复杂度 并发度 QPS AVG 50TH 90TH 95TH 99TH MAX CPU（峰值）
2C2G；新节点；0 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 1 83 11.13 11 17 18 19 158 30
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache 新框架 + 健康检查 1 84 11.04 11 17 18 19 88 30
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 健康检查 1 82 11.2 11 17 18 19 1674 38
2C2G；新节点；0 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 5 287 15.67 13 42 48 57 1682 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache 新框架 + 健康检查 5 290 15.66 12 42 48 58 171 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 健康检查 5 288 15.87 12 42 48 59 1730 100
2C2G；新节点；0 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 20 272 70.67 94 103 107 192 1740 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache 新框架 + 健康检查 20 273 70.5 94 103 107 193 2081 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 健康检查 20 272 71.34 94 103 107 192 1807 100
2C2G；新节点；0 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 50 239 200.04 200 302 398 497 1998 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache 新框架 + 健康检查 50 251 195.91 199 302 395 489 2105 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 健康检查 50 249 197.18 200 302 396 492 2183 100
2C2G；新节点；0 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 100 216 454.79 403 797 901 1200 2664 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache 新框架 + 健康检查 100 225 438.31 404 746 896 1193 2542 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 健康检查 100 222 444.76 407 744.9 892 1099 2443 100
  • PHP8.0 较比 7.4 在业务代码不动的状况下（基于 7.4 及之前语法）没有间接的性能晋升；
  • CPU 耗费大头不在 opcache 转 machine code 环节（想想也是）；
  • PHP8.0+Jit 目前无奈带来并发和性能体现的晋升。

IO 梗塞次数

资源状况 程序状况 接口复杂度 并发度 QPS AVG 50TH 90TH 95TH 99TH MAX CPU（峰值）
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 健康检查 1 156 2.71 6 6 6 8 198 30
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 简略逻辑 1 97 9.72 10 10 11 13 27 35
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 简略逻辑 *5 1 75 12.58 12 13 14 16 1607 27
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 简单逻辑 1 82 11.2 11 17 18 19 1674 38
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 健康检查 5 508 9.09 6 8 41 48 1653 99
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 简略逻辑 5 297 15.68 10 44 51 60 2046 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 简略逻辑 *5 5 282 16.51 13 34 43 53 1809 98
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 简单逻辑 5 288 15.87 12 42 48 59 1730 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 健康检查 20 451 42.92 8 93 94 96 1843 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 简略逻辑 20 275 70.91 94 101 104 191 1740 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 简略逻辑 *5 20 269 72.79 92 101 105 188 1809 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 简单逻辑 20 272 71.34 94 103 107 192 1807 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 健康检查 50 386 126.52 103 199 202 296 1989 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 简略逻辑 50 247 197.5 199 299 303 404 2079 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 简略逻辑 *5 50 246 200.26 199 298 301 400 2067 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 简单逻辑 50 249 197.18 200 302 396 492 2183 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 健康检查 100 357 273.75 292 399 473.65 510 2089 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 简略逻辑 100 233 424.72 402 602 697 897 2389 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 简略逻辑 *5 100 226 438.53 403 604 699 852.98 2417 100
2C2G；新节点；0 号正本 PHP-FPM8.0+OPcache+JIt 新框架 + 简单逻辑 100 222 444.76 407 744.9 892 1099 2443 100
  • 逻辑中不同水平的 IO 会导致单次申请的响应耗时减少，但对 CPU 的占用率影响较小；
  • 申请响应耗时高阻塞 IO 较比低阻塞 IO 广泛减少；
  • 并发度未将 CPU 打满时，高阻塞 IO 较比低阻塞 IO 的 QPS 体现要低；
  • 当并发度晋升将 CPU 打满后，高阻塞 IO 较比低阻塞 IO 的 QPS 体现简直统一

PDO 长连贯

资源状况 程序状况 接口复杂度 并发度 QPS AVG 50TH 90TH 95TH 99TH MAX CPU（峰值）
1C2G；原节点；2 号正本 PHP-FPM7.4+OPcache 新框架 + 简略逻辑 + 短连 1 139 6.56 5 6 6 15 2112 40
1C2G；原节点；2 号正本 PHP-FPM7.4+OPcache 新框架 + 简略逻辑 + 长连 1 207 4.23 3 4 4 9 1337 45
1C2G；原节点；2 号正本 PHP-FPM7.4+OPcache 新框架 + 简略逻辑 + 短连 2 241 7.33 5 6 12 33 1077 83
1C2G；原节点；2 号正本 PHP-FPM7.4+OPcache 新框架 + 简略逻辑 + 长连 2 356 4.62 3 4 6 22 1060 91
1C2G；原节点；2 号正本 PHP-FPM7.4+OPcache 新框架 + 简略逻辑 + 短连 5 274 16.37 5 66 74 86 1722 100
1C2G；原节点；2 号正本 PHP-FPM7.4+OPcache 新框架 + 简略逻辑 + 长连 5 427 10.33 3 9 67 73 1293 100
1C2G；原节点；2 号正本 PHP-FPM7.4+OPcache 新框架 + 简略逻辑 + 短连 20 265 73.19 93 103 196 302 1778 88
1C2G；原节点；2 号正本 PHP-FPM7.4+OPcache 新框架 + 简略逻辑 + 长连 20 393 49.31 12 97 100 103 1742 95
1C2G；原节点；2 号正本 PHP-FPM7.4+OPcache 新框架 + 简略逻辑 + 短连 50 253 195.05 198 300 398 599.79 1914 88
1C2G；原节点；2 号正本 PHP-FPM7.4+OPcache 新框架 + 简略逻辑 + 长连 50 345 142.96 102 200 202 300 2136 92
1C2G；原节点；2 号正本 PHP-FPM7.4+OPcache 新框架 + 简略逻辑 + 短连 100 241 401.15 397 601 705 1203.1 2644 99
1C2G；原节点；2 号正本 PHP-FPM7.4+OPcache 新框架 + 简略逻辑 + 长连 100 325 303.06 299 496 501 701 2205 100

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

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

框架截断

资源状况 程序状况 接口复杂度 并发度 QPS AVG 50TH 90TH 95TH 99TH MAX CPU（峰值）
1C2G；原节点；3 号正本 PHP-FPM7.4+OPcache 入口文件间接返回 20 6505 2.72 1 1 2 68 1774 100
1C2G；原节点；3 号正本 PHP-FPM7.4+OPcache 入口文件解析完申请 20 5956 2.72 1 1 1 69 1832 100
1C2G；原节点；3 号正本 PHP-FPM7.4+OPcache 引入主动加载之后 20 4341 3.61 1 1 2 77 2108 100
1C2G；原节点；3 号正本 PHP-FPM7.4+OPcache 加载我的项目配置之后 20 2278 8.16 1 2 86 89 1101 100
1C2G；原节点；3 号正本 PHP-FPM7.4+OPcache 加载底层配置之后 20 849 23.04 2 94 94 95 1867 100
1C2G；原节点；3 号正本 PHP-FPM7.4+OPcache 注册全副申请接口之后 20 630 30.97 2 95 96 97 1899 100
1C2G；原节点；3 号正本 PHP-FPM7.4+OPcache 健康检查残缺解决 20 516 37.62 3 96 97 98 1878 77

磨损次要产生环节：

  • 引入主动加载（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 优化就足够）。

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

资源状况 程序状况 接口复杂度 并发度 QPS AVG 50TH 90TH 95TH 99TH MAX CPU（峰值）
1C2G；原节点；4 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 + 不缓存配置 1 480 1.6 2 2 2 2 220 77
1C2G；原节点；4 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 + 缓存配置 1 705 1.05 1 1 2 2 1775 79
1C2G；原节点；4 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 + 不缓存配置 2 619 2.55 2 2 2 35 2526 100
1C2G；原节点；4 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 + 缓存配置 2 1083 1.54 1 1 2 26 2275 100
1C2G；原节点；4 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 + 不缓存配置 5 659 6.8 2 2 72 77 2409 100
1C2G；原节点；4 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 + 缓存配置 5 1060 4.36 1 2 2 72 2335 100
1C2G；原节点；4 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 + 不缓存配置 20 530 37.09 3 96 97 98 2398 100
1C2G；原节点；4 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 + 缓存配置 20 970 20.18 2 93 94 95 2601 100
1C2G；原节点；4 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 + 不缓存配置 50 469 105.58 100 196 198 231.99 2799 100
1C2G；原节点；4 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 + 缓存配置 50 946 52.22 90 98 99 103 2901 100
1C2G；原节点；4 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 + 不缓存配置 100 415 239.43 202 394 400 598 3000 100
1C2G；原节点；4 号正本 PHP-FPM7.4+OPcache 新框架 + 健康检查 + 缓存配置 100 920 107.89 100 195 199 289 2609 100

缓存配置较比不缓存对没有连贯和阻塞 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 高低，但最初几秒会呈现本地端口用尽的问题。

退出移动版