CODEWITHSUNDEEP
phpubuntunginxfile-get-contentsphp-7
Toskan
Toskan

Reputation: 14931

file_get_contents with full url to same server very slow with php 7 as of very recently on ubuntu 16.04

can it be that it is related to:

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

just a thought? probably not, because in the end, it actually works.

this used to be very quick, now takes like 7 seconds up to 26 seconds for a tiny image, that is stored locally as well.

"Well just change the code to no go via http" well i would prefer to not rewrite a library I am using to fix an issue that suddenly surfaced out of nowhere. If i perform the same call locally on my local dev machine it takes a splitsecond.

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

code:

   $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);
    }

example of url is:

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

access the image via browser is instant, e.g. if i type the url into the address bar

Upvotes: 0

Views: 1068

Answers (2)

Toskan
Toskan

Reputation: 14931

I got a response by digitalocean my server provider

We've received reports of a DNS outage affecting users that utilize Google's DNS servers, which is the default on all of our images. This droplet is in the affected IP range, so it is likely related to the issue.

Can you try using OpenDNS's servers, 208.67.222.222 and 208.67.220.220, as your primary or backup nameservers? This should resolve the issue you are facing. You can do this temporarily (it will persist until your next reboot) by editing /etc/resolv.conf to look like this: 

nameserver 208.67.222.222  
nameserver 208.67.220.220

So far everything points to this being an issue on Google's end, affecting UDP-based DNS queries from our 192.241.128.0/17 range. Eventually, queries can fall back to TCP, which allows them to succeed, but it takes several seconds explaining the slowness you're seeing. We've seen Google rate-limit or block selective IP ranges before, and it was very difficult to pin down. We've already reached out to Google and we are awaiting a response and resolution.

this worked

Upvotes: 1

sarnold
sarnold

Reputation: 104080

Check your /etc/resolv.conf file. A delay that long sounds a lot like you've got two nameservers in there that are useless.

Upvotes: 0

Related Questions