4 ms·

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

by gizmo 10y ago

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.

mrb 10y ago
"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 :)
- gizmo 10y ago
  In my experience TTL isn't respected at all. Clients will cache IP addresses no matter what.
  - mrb 10y ago
    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).
  - toast0 10y ago
    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.
  - szym 10y ago
    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_impl.cc?q=kMinimumTTLSeconds&sq=package:chromium&l=84&dr=CSs https://cs.chromium.org/chromium/src/net/dns/host_resolver_i...
aab0 10y ago
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.
- mrb 10y ago
  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.
  - fweespeech 10y ago
    > 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.
    - mrb 10y ago
      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.
ploxiln 10y ago
DNS lookups can be and are cached for a while - but the collection of IPs returned (up to 8 IIRC) should all be cached.
vanzard 10y ago
"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.

by gizmo 10y ago

mrb 10y ago

"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 :)

gizmo 10y ago
In my experience TTL isn't respected at all. Clients will cache IP addresses no matter what.
- mrb 10y ago
  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).
- toast0 10y ago
  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.
- szym 10y ago
  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_impl.cc?q=kMinimumTTLSeconds&sq=package:chromium&l=84&dr=CSs https://cs.chromium.org/chromium/src/net/dns/host_resolver_i...

aab0 10y ago

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.

mrb 10y ago
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.
- fweespeech 10y ago
  > 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.
  - mrb 10y ago
    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.

ploxiln 10y ago

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

vanzard 10y ago

"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.