关于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	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高低，但最初几秒会呈现本地端口用尽的问题。