最近在 ubuntu 16.04 上使用 php 7 到同一服务器的完整 url 的 file_get_contents 非常慢答案

【问题标题】：file_get_contents with full url to same server very slow with php 7 as of very recently on ubuntu 16.04最近在 ubuntu 16.04 上使用 php 7 到同一服务器的完整 url 的 file_get_contents 非常慢
【发布时间】：2017-08-20 14:25:55
【问题描述】：

会不会是跟以下有关：

https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1674733

只是一个想法？可能不会，因为最终它确实有效。

这在过去非常快，现在需要 7 秒到 26 秒来处理一个很小的图像，该图像也存储在本地。

“好吧，只需将代码更改为不通过 http 进行”好吧，我宁愿不重写我用来解决突然冒出来的问题的库。如果我在本地开发机器上本地执行相同的调用，则需要一瞬间。

myapp/public/caup_laravel/vendor/intervention/image/src/Intervention/Image/AbstractDecoder.php

代码：

   $options = array(
        'http' => array(
            'method'=>"GET",
            'header'=>"Accept-language: en\r\n".
            "User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.2 (KHTML, like Gecko) Chrome/22.0.1216.0 Safari/537.2\r\n"
      )
    );

    $context  = stream_context_create($options);
    if ($data = @file_get_contents($url, false, $context)) { //VERY slow call
        return $this->initFromBinary($data);
    }

网址示例：

http://dev.causepick.org/caup_api/uploads/causes/52/cropped-436535-a42b2.jpg

通过浏览器访问图像是即时的，例如如果我在地址栏中输入网址

【问题讨论】：

您是否尝试过像该错误报告中的人一样重新启动？
同一台机器上的其他文件是否也很慢？你能用nslookup dev.causepick.org之类的东西在那个服务器上测试DNS查找吗？如果服务器的 DNS 导致对该域的查找缓慢，则可以解释从其他计算机看不到的延迟。
我重新启动了机器是的 @MichaelBerkowski 它可以工作，但以下事情：如果我这样做 ping google.com 我必须等待 15 秒才能获得第一个结果。所以在 15 秒内什么都没有发生，然后结果以低测量响应时间出现，不知何故忽略了我基本上在 CLI 中等待了很多秒的事实。类似dev.causepick.org
重试了几次，只是说：刚刚得到$ ping dev.causepick.org ping: unknown host dev.causepick.org 下次我尝试，它再次工作。然后它甚至很快。再试一次...有效，但速度很慢。
我现在意识到上周我可能在 Ubuntu 工作站上遇到了同样的错误，我每 3-4 小时就会丢失一次 DNS。

标签： php ubuntu nginx file-get-contents php-7

【解决方案1】：

检查您的/etc/resolv.conf 文件。这么长的延迟听起来很像你有两个无用的域名服务器。

【讨论】：

8.8.8.8 和 8.8.4.4

【解决方案2】：

我的服务器提供商 digitalocean 收到了回复

我们收到了有关 DNS 中断影响使用的用户的报告 Google 的 DNS 服务器，这是我们所有图片的默认设置。这 droplet 在受影响的 IP 范围内，因此它可能与问题。

您可以尝试使用 OpenDNS 的服务器 208.67.222.222 和 208.67.220.220，作为您的主要或备用域名服务器？这应该可以解决您面临的问题。您可以暂时执行此操作（它将坚持到你下次重新启动）通过编辑 /etc/resolv.conf 来查看像这样：

nameserver 208.67.222.222  
nameserver 208.67.220.220

到目前为止，一切都表明这是 Google 的问题，影响我们 192.241.128.0/17 范围内基于 UDP 的 DNS 查询。最终，查询可以回退到 TCP，这允许它们成功，但需要几秒钟来解释你的缓慢看到。我们已经看到 Google 限制或阻止选择性 IP 范围以前，很难确定。我们已经到达联系 Google，我们正在等待回复和解决方案。

成功了

【讨论】：