4 ms·

Seems like DNS TTL was a big issue before HTTP 1.1. Connections are cached and reused.

zamadatix 7y ago
If you're talking about keep-alive this times out far before most of the DNS TTLs mentioned in this article and don't persist after a connection is closed anyways.
- ryanthedev 7y ago
  That's not true. It all depends on the implementation... Also what are you talking about? If the connection is closed, how would it be used? Connections should only be closed due to? Inactivity. If a connection is closed, don't you think you would probably want to do another DNS request? Also if your doing proper layer 4 load balancing using BGP, DNS is a moot point... Magic...
  - zamadatix 7y ago
    > Connections should only be closed due to? Inactivity. Or if the user closes the browser of if the server/proxy restarts. But yes, mostly inactivity on the order of a couple of minutes. > If a connection is closed, don't you think you would probably want to do another DNS request? That's the whole point of the DNS TTL, to say how long to go before doing another lookup rather than doing it each time you reconnect. > Also if your doing proper layer 4 load balancing using BGP, DNS is a moot point... BGP load balancing operates on layer 3, and is irrelevant as you still need to DNS lookup an anycast address. EDNS client subnet is better anyways.
    - ryanthedev 7y ago
      An anycast address doesn't change. I mean come on. And it actually operates on layer 4. It uses layer 4 to actually work? I hope you didn't pay for your education.
      - zamadatix 7y ago
        Anycast addresses change all the time. Ask Google, Microsoft, Amazon, Akamai, Cloudlfare and so on if you don't believe me. About the only anycast IPs that don't change are public DNS resolvers but that's also true of unicast resolvers as well. By that logic BGP is a layer 7 load balancer since it has an application layer. BGP only exchanges layer 3 reachability information to update route tables therefore you can only load balance layer 3 with it. Personal attacks and other things in your comments are against the HN guidelines. The goal is to talk about DNS/TTLs and their impact on performance not insult each other. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- ryanthedev 7y ago
  Also, wtf are you talking about? Did you even read the article? Most sit between? 0-15 minutes. WTF is your timeout?
  - zamadatix 7y ago
    > Also, wtf are you talking about? TTLS. > Did you even read the article? Sure did which is why I referenced it. > Most sit between? 0-15 minutes. This is true in that the range encapsulates most keep-alive timeouts not in that keepalives longer than a minute or two are actually the majority. nginx defaults to 100 seconds, Apache is less than that. Most don't mess with these let alone bump them to 900. Generally 60 to 120 is considered standard with some cap on the number of active keep-alive sessions as well. Some go ultra-low or disable it all together, very few go ultra-high. > WTF is your timeout? 120. Also please try to keep the conversations together.
    - ryanthedev 7y ago
      TTLS isn't a thing. You're argument about keep alive makes no sense. You're confusing the nginx documentation. 100 is the number of default connections it will hold open. 60 is the default timeout. Also it's sent as an HTTP response to the client in the headers... Here you need to read up: https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout https://nginx.org/en/docs/http/ngx_http_core_module.html#kee... The timeout only matters if you're not making requests. Setting a low keep alive will actually result in more DNS requests...doh Next you're going to tell me you only write blocking code and use a thread per connection... I guess you haven't created many 10k concurrent app servers.
      - zamadatix 7y ago
        Meant "TTLs" as in the plural of TTL but my phone capitalized the whole block on me. > You're argument about keep alive makes no sense. You're confusing the nginx documentation. 100 is the number of default connections it will hold open. 60 is the default timeout. Also it's sent as an HTTP response to the client in the headers... Here you need to read up: http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout http://nginx.org/en/docs/http/ngx_http_core_module.html#keep... Are you're right about the 100 being the default active keepalives not the default timeout. According to your own nginx link 75 is the timeout not 60 though: "Default: keepalive_timeout 75s;" Either way, 75/60/100/120 are significantly far off from 15 minutes. > The timeout only matters if you're not making requests. Or if the server reaches max connections. > Setting a low keep alive will actually result in more DNS requests...doh Which is how the discussion on DNS TTLs comes about in the first place. It's trivial to set the DNS TTL astronomically higher than the HTTP keep-alive, in which case the browser & OS won't actually make a lookup request since it's cached.

If you're talking about keep-alive this times out far before most of the DNS TTLs mentioned in this article and don't persist after a connection is closed anyways.

ryanthedev 7y ago
That's not true. It all depends on the implementation... Also what are you talking about? If the connection is closed, how would it be used? Connections should only be closed due to? Inactivity. If a connection is closed, don't you think you would probably want to do another DNS request? Also if your doing proper layer 4 load balancing using BGP, DNS is a moot point... Magic...
- zamadatix 7y ago
  > Connections should only be closed due to? Inactivity. Or if the user closes the browser of if the server/proxy restarts. But yes, mostly inactivity on the order of a couple of minutes. > If a connection is closed, don't you think you would probably want to do another DNS request? That's the whole point of the DNS TTL, to say how long to go before doing another lookup rather than doing it each time you reconnect. > Also if your doing proper layer 4 load balancing using BGP, DNS is a moot point... BGP load balancing operates on layer 3, and is irrelevant as you still need to DNS lookup an anycast address. EDNS client subnet is better anyways.
  - ryanthedev 7y ago
    An anycast address doesn't change. I mean come on. And it actually operates on layer 4. It uses layer 4 to actually work? I hope you didn't pay for your education.
    - zamadatix 7y ago
      Anycast addresses change all the time. Ask Google, Microsoft, Amazon, Akamai, Cloudlfare and so on if you don't believe me. About the only anycast IPs that don't change are public DNS resolvers but that's also true of unicast resolvers as well. By that logic BGP is a layer 7 load balancer since it has an application layer. BGP only exchanges layer 3 reachability information to update route tables therefore you can only load balance layer 3 with it. Personal attacks and other things in your comments are against the HN guidelines. The goal is to talk about DNS/TTLs and their impact on performance not insult each other. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
ryanthedev 7y ago
Also, wtf are you talking about? Did you even read the article? Most sit between? 0-15 minutes. WTF is your timeout?
- zamadatix 7y ago
  > Also, wtf are you talking about? TTLS. > Did you even read the article? Sure did which is why I referenced it. > Most sit between? 0-15 minutes. This is true in that the range encapsulates most keep-alive timeouts not in that keepalives longer than a minute or two are actually the majority. nginx defaults to 100 seconds, Apache is less than that. Most don't mess with these let alone bump them to 900. Generally 60 to 120 is considered standard with some cap on the number of active keep-alive sessions as well. Some go ultra-low or disable it all together, very few go ultra-high. > WTF is your timeout? 120. Also please try to keep the conversations together.
  - ryanthedev 7y ago
    TTLS isn't a thing. You're argument about keep alive makes no sense. You're confusing the nginx documentation. 100 is the number of default connections it will hold open. 60 is the default timeout. Also it's sent as an HTTP response to the client in the headers... Here you need to read up: https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout https://nginx.org/en/docs/http/ngx_http_core_module.html#kee... The timeout only matters if you're not making requests. Setting a low keep alive will actually result in more DNS requests...doh Next you're going to tell me you only write blocking code and use a thread per connection... I guess you haven't created many 10k concurrent app servers.
    - zamadatix 7y ago
      Meant "TTLs" as in the plural of TTL but my phone capitalized the whole block on me. > You're argument about keep alive makes no sense. You're confusing the nginx documentation. 100 is the number of default connections it will hold open. 60 is the default timeout. Also it's sent as an HTTP response to the client in the headers... Here you need to read up: http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout http://nginx.org/en/docs/http/ngx_http_core_module.html#keep... Are you're right about the 100 being the default active keepalives not the default timeout. According to your own nginx link 75 is the timeout not 60 though: "Default: keepalive_timeout 75s;" Either way, 75/60/100/120 are significantly far off from 15 minutes. > The timeout only matters if you're not making requests. Or if the server reaches max connections. > Setting a low keep alive will actually result in more DNS requests...doh Which is how the discussion on DNS TTLs comes about in the first place. It's trivial to set the DNS TTL astronomically higher than the HTTP keep-alive, in which case the browser & OS won't actually make a lookup request since it's cached.