Making an HTTP request from my Droplet is painfully slow (DNS lookup issue?)

November 24, 2014 4k views
octopi
By:
octopi

It takes 10+ seconds for an HTTP request from my Droplet to another server to complete. I can confirm that it’s not an issue with poor application code, but something deeper at the networking level. Just running basic curl and outputting timings produces:

$ curl -w "@curl-timings" -o /dev/null -s google.com

            time_namelookup:  10.044
               time_connect:  10.045
            time_appconnect:  0.000
           time_pretransfer:  10.045
              time_redirect:  0.000
         time_starttransfer:  10.065
                            ----------
                 time_total:  10.065

But as soon as you replace the domain name:

$ curl -w "@curl-timings" -o /dev/null -s 173.194.123.70

            time_namelookup:  0.000
               time_connect:  0.001
            time_appconnect:  0.000
           time_pretransfer:  0.001
              time_redirect:  0.000
         time_starttransfer:  0.039
                            ----------
                 time_total:  0.039

This smells like something to do with how my Droplet is performing DNS lookup/resolution, but I don’t really know where to start looking or what to poke around at. Any help?

3 comments
  • andol November 24, 2014
    Report

    What does your /etc/resolv.conf look like? If you run a dig google.com, from where does it say the response come? At the bottom, look for a line starting with ;; SERVER:.

  • octopi November 24, 2014
    Report

    resolv.conf below, also a little weird that I can’t reach 4.2.2.2. 8.8.8.8 works fine and seems to be what’s actually being used.

    $ cat resolv.conf
nameserver 4.2.2.2
nameserver 8.8.8.8

    $ ping 4.2.2.2
PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data.
^C
--- 4.2.2.2 ping statistics ---
12 packets transmitted, 0 received, 100% packet loss, time 11087ms

    $ dig facebook.com

; <<>> DiG 9.8.1-P1 <<>> facebook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28922
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;facebook.com.          IN  A

;; ANSWER SECTION:
facebook.com.       803 IN  A   173.252.120.6

;; Query time: 15 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Nov 24 04:40:31 2014
;; MSG SIZE  rcvd: 46
  • octopi November 24, 2014
    Report

    Modified the file and moved Google’s DNS to the top and things are working better! I wonder what actually happened here though?

Sign In to Comment
1 Answer
andol November 24, 2014

Seems like the problem is that you are listing a resolver 4.2.2.2, which doesn’t want anything to do with your droplet. The delay you suffered were from every lookup first timing out on the first entry before moving on to the second.

Unless you have any particular reason for wanting to use 4.2.2.2, you might instead want to use both the Google resolvers in your resolv.conf

nameserver 8.8.8.8
nameserver 8.8.4.4
Report
Have another answer? Share your knowledge.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!