识别哪些会产生壅塞式调用的操作，是预防这一危急最基本的哀求。
不要说刚学习PHP的新手，哪怕是从事了多年PHP开拓的同学，估计也会对这一块有所遗漏。

4.4.1 file_get_contents()真的好吗

从我最初打仗商业项目的开拓，就看到项目中会用到file_get_contents()函数获取远程做事器上的数据文件。
到现在，过去了靠近十年，在商业项目中仍旧看到大量地利用file_get_contents()函数调用远程接口做事，或者用于获取远程图片资源。

file_get_contents()函数利用很大略，这也难怪为什么会有很多开拓同学会喜好它，乃至是不加思虑就喜好它，甚至在项目开拓盲目傅用它，险些能用到的地方都用上。
由于它不仅可以读取本地系统的文件资源，还可以获取远程做事器的资源。
但这个函数有个最大的弊端，便是无法设置超时时间。
如果须要获取的远程资源，或者待要求的接口一贯无法相应的话，就会导致壅塞。
如果这一超时的接口或者页面又恰好是外部频繁访问时，就会导致大量的php-fpm进程被占用。
末了，全体系统处于满负载运行状态，由于php-fpm进程资源得不到开释。

php设置超时PHP高等编程回归原生态谨防壅塞式挪用 Ruby

要仿照这一征象也不难，下面我们来考试测验一下。
看下当涌现这种情形时，会有哪些征象，以及该怎么改进和应对。

先来调度一下php-fpm的干系配置。
把php-fpm进程改成静态实行，最大进程数改为5个，并且把PHP处理的超时时间设置为60秒。
如下：

; pm = dynamicpm = static;pm.max_children = 5pm.max_children = 5;request_terminate_timeout = 0request_terminate_timeout = 60修正后，重启php-fpm。

然后，添加一个PHP文件，并在里面通过file_get_contents()函数获取接口http://api.okayapi.com/返回的信息并输出。
如下：

# $ vim ./file_get_contents.php<?php$rs = file_get_contents('http://api.okayapi.com/');echo $rs;

非常大略的代码。
访问一下，可以看到正常的结果输出。

但是如果涌现非常情形呢？例如我们可以给api.okayapi.com故意绑定一个缺点的IP地址，让它无法正常连接。
以root用户权限修正/etc/hosts文件，并在末了添加：

192.168.22.33 api.okayapi.com

再重新要求前面的链接，会在等待1分钟后，提示：504 Gateway Time-out。
如果同时对此发起5次及以上的要求，再额外要求其他页面，就会涌现卡住的征象。
这是由于做事真个5个php-fpm进程已经全部在做事./file_get_contents.php这个要求，很难再抽身出来相应新的要求。
而查看Nginx的缺点日志，可以创造有Resource temporarily unavailable这样的缺点提示。

办理改进的方案便是利用可以设置超时的办法来获取远程做事端资源，一如随处颂扬的curl。
作为比拟，其余新建一个curl.php文件，并输入以下代码：

<?php// 创建新的 cURL 资源$ch = curl_init();// 设置 URL 和相应的选项curl_setopt($ch, CURLOPT_URL, "http://api.okayapi.com/");curl_setopt($ch, CURLOPT_HEADER, 0);curl_setopt($ch, CURLOPT_TIMEOUT, 3);// 抓取 URL 并把它通报给浏览器$rs = curl_exec($ch);echo $rs;// 关闭 cURL 资源，并且开释系统资源curl_close($ch);

上面代码，将最长实行韶光CURLOPT_TIMEOUT设置为3秒，当超过这个韶光就会停滞连续实行。
这样会更为可控，由于你自己的系统可以知道发生了超时的情形，超时情形下curl_exec()返回的结果是FALSE。
针对超时，你可以进行报警、容错、降级等处理，而不是漫无目的地一贯等待。

我们阻挡不了问题的发生，但可以改进处理问题的办法。
建议除非读取的是本地文件资源，否则只管即便在获取远程资源时利用cURL，而不是file_get_contents()，尤其有要求接口时。

除此之外，还要甄别其他由于无法设置超时而导致壅塞的函数和操作。
这里不过多展开，但例如取得图像大小的getimagesize()函数便是个中一个。
曾经在现实系统中，我也遇见过由于这个函数利用不当而导致全体页面无法访问的故障。
希望大家引以为鉴。

4.4.2 让我“睡”一下

导致壅塞的缘故原由可以划分为两大类，一类是前面所说的，由于外部缘故原由而导致的超时壅塞，这是不可控的。
但其余一类，提及来有点可笑，由于是可控的，并且是内部缘故原由，是开拓职员（很可能便是你自己）一手造成的。

PHP有三个函数可用于延缓实行，分别是：

sleep() 延缓实行usleep() 以指定的微秒数延迟实行time_sleep_until() — 使脚本就寝到指定的韶光为止

包括我在内，很多PHP程序员都喜好利用这几个就寝函数。
但这几个函数是有一定弊端的，缘故原由和前面类似。
对付每个要求，php-fpm都是单进程壅塞式地相应。
任何PHP的操作，基本都是同步操作，与Javascript的机制截然不同。
虽然Javascript也是单进程，但它可以做到事宜轮询，触发式回调相应，因此不会造成壅塞。

曾经我见过一个很可笑但又隐蔽重大问题的真实案例。
用户在揭橥评论的同时，可以上传多张图片。
由于须要判断用户的图片是否已全部上传完毕，做事端以为须要“等一等”，等用户全部的图片都上传完毕后才能将评论内容连带图片一起fjtf持久化储存。
它的做法是，在判断图片是否已上传完毕的接口里，最多等待10次，每等待一次就调用sleep()函数延缓实行1秒钟，然后每次都是检讨图片是否上传完毕。
此做法导致该接口每次相应的韶光均匀都是好几秒，最坏情形下去到10秒！

这种对sleep()不合理的调用，不仅导致了当前要求相应慢，会产生PHP慢调用外，当流量过大时，同样会涌现上述全部php-fpm进程被占满导致系统不可用的故障。
这是做事端资源的间接摧残浪费蹂躏，由于php-fpm进程无法及时开释出来做一些更故意义的事情。
令我惊异的是，当我和掩护这块代码的工程师谈论为什么要这样做时，他竟然见告我此做法性能更高效，由于可以减少客户真个多次要求。
天哪！
于是我不得反面他阐明了一下为什么延迟实行的方案非但不高效反而祸患重重。

假设，要求一次判断图片是否已上传完毕的接口，须要100毫秒。
原来的做法，在做事端检测一次就等待1秒，即对付做事端来说，CPU的有效韶光利用率只有9%，由于有1000毫秒是毫无用途，白白摧残浪费蹂躏的。

如果换一种做法，让客户端来轮询的话，那么虽然客户端会发起多次要求，最多会考试测验10次。
也便是把做事真个循环检测移到客户端来实行。
那么，原来就寝的1000毫秒，就可以开释出来做事其他要求或页面的要求。
即剩下的91%的有效韶光可以连续充分利用，连续相应其他要求，不至于被摧残浪费蹂躏。

图4-6 两种做法的韶光比拟