PHPPHP性能优化之连接超时

此间抛出一个普遍问题: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服务框架,在大并发的前提下才能感知到效益。

据悉不同的事体要求做技术采用。

相关文章