4 ms·

I think it'd be more interesting to measure the impact on the end user. The article mentions a drop in queries, but aren't DNS queries a drop in the bucket comp

by hiq 6y ago

I think it'd be more interesting to measure the impact on the end user. The article mentions a drop in queries, but aren't DNS queries a drop in the bucket compared to the size of most web pages anyway? Is the difference really noticeable? Do you get faster web pages if you cache for a longer time? If you do, shouldn't web browsers "soft-invalidate" (use the entry, but update it right after) the cache entry when you're just past TTL and "hard-invalidate" (update it before using) after? Do they do that already?

yarcob 6y ago
> aren't DNS queries a drop in the bucket compared to the size of most web pages anyway? The client needs to wait for the result of a DNS query before it can do anything else. The bandwidth is irrelevant, the problem is the delay. Usually DNS queries are cached by a server near the user, so they are very fast. But if the authoritative name server has a very short TTL, then those cached results will often be stale, and the name server has to resolve the name recursively, which can be slow.
- hiq 6y ago
  > The client needs to wait for the result of a DNS query before it can do anything else. The bandwidth is irrelevant, the problem is the delay. You're right. But the article seems to claim the number of queries can be reduced with a higher TTL, which is why these should be enforced. Fair enough, but so what? In any case, the TTL is irrelevant for the first query. For the next ones, if you allow yourself to rely on the previous result (the "soft-invalidation" I mentioned, for lack of a better word), it shouldn't have any impact for the user.
  - yarcob 6y ago
    > TTL is irrelevant for the first query With a long TTL, the chances are higher that your router or your ISP has the name cached. Round trip to your ISP is very short. If you have a short TTL, the ISPs name server may have to query the next server in the chain. If the authoritative name server is 10000km away, that means at least 60ms extra round trip time (speed of light).
cactus2093 6y ago
I thought the same thing. This post included lots of data about the system-wide behavior of the DNS system, but no data about the end user experience. It's obvious there will be some reduced latency for users, but what is the distribution there in the real world? If the mean is like 10ms extra or something, it's not really worth optimizing for anybody except maybe the very biggest players on the web (and even they might decide the trade-offs are not worth it). It's just very easy to shoot yourself in the foot with a long DNS TTL, in the worst case taking down your entire site until the TTL expires if you ever misconfigure it. Why risk it for a small gain? Also, even theoretically it's not clear to me that it would help end user experience. Someone correct me if I'm wrong, but I believe if there's already an open connection from the browser to the server based on the TCP keep-alive settings, the browser will continue to use it rather than kill it and open a new connection starting with a DNS lookup even if the DNS TTL expires. So for an otherwise well-tuned site, each user session should expect to do a DNS lookup at the start of the session but then the rest of the requests in that session won't need to. If that's true, then the only way DNS TTL will affect the end user experience is if the TTL is long enough such that there are a significant number of instances where the time between sessions for one user on the same device is longer than the DNS TTL. Most sites don't have their users returning every 30 minutes, they're lucky to get someone as a daily active or even weekly active user. So the TTL might have to be ~ a few days long to impact a significant number of users (and even then, probably only by a few tens of milliseconds at the beginning of the session).
xg15 6y ago
I have no data, but I think it should make a difference. The impact is not about bandwidth but about latency, so the size of a query plays no role - what does play a role is how many network roundtrips the browser has to do before the page becomes usable. Seems to me that short TTLs in connection with the current trend to include scripts from dozens of different domains could easily double the number of average roundtrips per page load here.
jontro 6y ago
I think the impact of a low ttl is negligible for web sites. It would at least be nice with some actual measurements. The first visit wouldn't be dns-cached anyways and subsequent page loads will have other static resources already cached.

by hiq 6y ago

yarcob 6y ago

> aren't DNS queries a drop in the bucket compared to the size of most web pages anyway? The client needs to wait for the result of a DNS query before it can do anything else. The bandwidth is irrelevant, the problem is the delay. Usually DNS queries are cached by a server near the user, so they are very fast. But if the authoritative name server has a very short TTL, then those cached results will often be stale, and the name server has to resolve the name recursively, which can be slow.

hiq 6y ago
> The client needs to wait for the result of a DNS query before it can do anything else. The bandwidth is irrelevant, the problem is the delay. You're right. But the article seems to claim the number of queries can be reduced with a higher TTL, which is why these should be enforced. Fair enough, but so what? In any case, the TTL is irrelevant for the first query. For the next ones, if you allow yourself to rely on the previous result (the "soft-invalidation" I mentioned, for lack of a better word), it shouldn't have any impact for the user.
- yarcob 6y ago
  > TTL is irrelevant for the first query With a long TTL, the chances are higher that your router or your ISP has the name cached. Round trip to your ISP is very short. If you have a short TTL, the ISPs name server may have to query the next server in the chain. If the authoritative name server is 10000km away, that means at least 60ms extra round trip time (speed of light).

cactus2093 6y ago

I thought the same thing. This post included lots of data about the system-wide behavior of the DNS system, but no data about the end user experience. It's obvious there will be some reduced latency for users, but what is the distribution there in the real world? If the mean is like 10ms extra or something, it's not really worth optimizing for anybody except maybe the very biggest players on the web (and even they might decide the trade-offs are not worth it). It's just very easy to shoot yourself in the foot with a long DNS TTL, in the worst case taking down your entire site until the TTL expires if you ever misconfigure it. Why risk it for a small gain? Also, even theoretically it's not clear to me that it would help end user experience. Someone correct me if I'm wrong, but I believe if there's already an open connection from the browser to the server based on the TCP keep-alive settings, the browser will continue to use it rather than kill it and open a new connection starting with a DNS lookup even if the DNS TTL expires. So for an otherwise well-tuned site, each user session should expect to do a DNS lookup at the start of the session but then the rest of the requests in that session won't need to. If that's true, then the only way DNS TTL will affect the end user experience is if the TTL is long enough such that there are a significant number of instances where the time between sessions for one user on the same device is longer than the DNS TTL. Most sites don't have their users returning every 30 minutes, they're lucky to get someone as a daily active or even weekly active user. So the TTL might have to be ~ a few days long to impact a significant number of users (and even then, probably only by a few tens of milliseconds at the beginning of the session).

xg15 6y ago

I have no data, but I think it should make a difference. The impact is not about bandwidth but about latency, so the size of a query plays no role - what does play a role is how many network roundtrips the browser has to do before the page becomes usable. Seems to me that short TTLs in connection with the current trend to include scripts from dozens of different domains could easily double the number of average roundtrips per page load here.

jontro 6y ago

I think the impact of a low ttl is negligible for web sites. It would at least be nice with some actual measurements. The first visit wouldn't be dns-cached anyways and subsequent page loads will have other static resources already cached.