PHP性能优化之连接超时

这里抛出一个常见问题:PHP环境下脚本运行超时,尤其是处理后台服务数据处理时经常会遇到。

Maximum execution time of 120 seconds exceeded

常规解决排查方式

我们的排查思路一般从数据量开始,主观判断由于程序需要处理的数据过多,造成运行处理时间过长,超出了系统限定的脚本最大执行时间。那么真的是处理的数据过多,还是程序写法或者逻辑存在风险问题?我们从以下几个方面分析

1 瓶颈出现在数据库层面,比如关系型或者nosql数据库中的字段缺失,即字段拼写错误,造成数据库查询卡死或者数据库数据量巨大,没有在条件字段下建立索引。这种情况下,程序会一直等待数据库操作的返回,脚本自然会中断报错。

Read timed out after reading 0 bytes, waited for 30.000000 seconds

2 减少单次处理的数据量,避免foreach中循环操作数据库

数据库层面能够顺利读取数据,常规循环次数过多,应用服务器与数据库服务器IO频率过高仍然会出现以上问题。

3 程序过程中涉及到大数组的读取,合并,组合,造成内存过载,比如PHP的最大使用内存是128M,而一个脚本耗时几分钟,使用内存达到50M,着这样的比例,长期来看必定存在风险。

PHP内置函数memory_get_usage()能返回当前分配给PHP脚本的内存量,单位是字节(byte).

memory_get_peak_usage()函数返回内存使用峰值,getrusage()返回CUP使用情况。

如何解决

第一种解决方式: 最简单,但是不持久,不合理

从配置的角度解决

脚本中设定程序执行不超时,set_time_limit(0);

内存使用不限制,ini_set('memory_limit',0);

增加脚本超时时间,合作加大内存使用M数。

第二种解决方式对症下药

合理存取数据,优化数据库结构,优化数据存取比例和程序逻辑,通过unset释放大数组。

索引优化

实际例子,一张100万数据量的MongoDb集合增加普通的索引,即可让一次从1o几秒的查询耗时降低到0.1秒以下。可以预见这样的程序性能提升。

以上讨论的解决方式都能正确解决问题吗,我们发现以上的解决方式都局限在同步编程模型下,更深层次深究,或许我们应该从同步处理的思维下,转换为异步思维。

在php-fpm模式下,php处理耗时比较长任务时,会发生堵塞,此时可以用异步方法,将该任务抛出,程序继续向下执行

那么PHP应用程序编程有哪些常见的异步处理方式

使用Redis做中转,分离数据与程序,结合消息队列异步处理长时间的大数据耗时任务

或者引入Swool服务框架,在大并发的前提下才能感知到效果。

根据不同的业务需求做技术选择。