Hacker News Reader

Comment by gizmo | Hacker News Reader

After the DNS resolves the IP will be cached by the client for hours. So if any server goes down the blog goes down with it for those users. If you can't reboot any server without causing downtime I don't think it can be called high availability.

Taking a simple jackyl blog on a single instance and adding cloudflare would work much more reliably, and it doesn't require all sorts of rsync tricks.

View on HN

"After the DNS resolves the IP will be cached by the client for hours"

Not true because my TTL is low (5 min). Chrome will even try another IP within tens of seconds if the initial IP becomes unresponsive. I tested this on Linux. That said I recognize this is not a production-quality mechanism to implement HA (large sites or CDN providers use anycast, load balancers, etc.) But for a personal blog, this is perfectly fine :)

In my experience TTL isn't respected at all. Clients will cache IP addresses no matter what.

I tested this pretty extensively. When I switched IPs, 99.9% of the HTTP traffic hit the new servers within the TTL time (5min). The only residual traffic hitting the old IPs I saw was from poorly configured bots & webspiders who probably don't re-resolve hostnames frequently enough.

I remember also reading a post from Amazon EC2 Route 53 engineers who investigated DNS propagation times across large-scale tests in the world, and my observations aligned with theirs. They concluded the "DNS doesn't propagate according to TTL" story is mostly a myth (modulo rare issues here and there).

We use DNS for rotations at work. When we make a change, traffic starts moving right away, and most of the traffic moves within two or three TTLs. Most browsers do have some compensation mechanisms when some servers in the list don't respond, and will do even better if some servers are refusing connections. There are lingering connections for a long time though -- I think some DNS servers do cache until they are restarted.

The load balancers we have available to us had worse uptime and scalability than our servers, so DNS it is. It would be nice to fully drain servers in a reasonable amount of time, but I can deal with it.

Indeed, for example Chrome wants to cache DNS results for at least a minute [1].

However, Chrome and Firefox cache the complete DNS/getaddrinfo response, i.e. all addresses. Therefore a server taken out of rotation will be quickly identified when a socket connection fails.

[1] https://cs.chromium.org/chromium/src/net/dns/host_resolver_i...

  "adding cloudflare would work much more reliably"

This can't work. The author requirement was to have self-hosted comments without javascript. So his html pages change every few minutes, and cloudflare is just not designed for this.

DNS lookups can be and are cached for a while - but the collection of IPs returned (up to 8 IIRC) should all be cached.

You don't even need the instance if it's a static site that can be served directly off S3. With S3+Cloudflare for a Jekyll blog, you can handle peaking to thousands of hits a second without noticing it at like $10/month.

How well do S3 and Cloudflare handle a page changing potentially every 2-3 minutes? I was under the impression S3 is not made for this use case.

> How well do S3 and Cloudflare handle a page changing potentially every 2-3 minutes? I was under the impression S3 is not made for this use case.

It isn't made for that use case...the CDN provider I use takes ~15 minutes to update its Push Zone globally.

However, a pair of $5 VMs and loading comments via JS "solves" the need for dynamic updates since comments are the only thing likely to change frequently. Personally, I don't have much need for hosted comments so I don't bother.

OK that's what I thought. S3 isn't a solution. One of my requirements was: no JS needed to read a post and associated comments.

Reply on news.ycombinator.com