Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cloudflare Network Performance Issues

cloudflarestatus.com

Post reply on HN
Print view View original

261–270 of 329 posts

Re: Cloudflare Network Performance Issues

#261

Post by kortilla »

btown wrote: post #252
profmonocle wrote: post #231

Once cloudflare.com came back I decided to check out their business SLA, and it's not very encouraging: > For any and each Outage Period during a monthly billing period the Company will provide as a Service Credit an amount calculated as follows: Service Credit = (Outage Period minutes * Affected Customer Ratio) ÷ Scheduled Availability minutes - https://www.cloudflare.com/business-sla/ So assuming an outage affects…

This doesn't surprise me at all - SLA's are widely overrated. No SLA will cover damages incurred by lost business due to an outage. What you likely want is some kind of third-party insurance for downtime caused by outages out of your control - but I'm not even sure this exists.

I guess you’ve never worked in enterprise. SLAs for critical systems very frequently incur payback in excess of the billing on outages.

Re: Cloudflare Network Performance Issues

#262

Post by pmlnr »

eeeeeeeeeeeee wrote: post #236
pmlnr wrote: post #72

Good. I'm tired of people not learning that trusting a single gateway with 50% of the internet is bad. Yes, I know, free DDOS protection. There has to be another way of doing this, some mesh based DDOS protection or so.

I agree that the centralization of the internet is troubling, but Cloudflare is solving a systemic problem that nobody else is tackling. The DDoS problem was not being solved for anyone except for enterprise customers until Cloudflare came along and to this day there is very little competition in this space. Your post makes it sound like making a "mesh based DDoS" system is somehow trivial. Who is going to pay for th…

> Your post makes it sound like making a "mesh based DDoS" system is somehow trivial.

It does not. "There has to be" ends in "!" and is an expression is a wish.

> Who is going to pay for this?

All of us. Everyone. I keep circling back to the idea that we should all join a protection ring, so we'd all share "cost" on this.

> How do you ensure latency is not atrocious? > Why hasn't someone made this already?

First one is very technical, and the answer is most probably by localisation and by only actually turning it on when needed.

For the second: because it's a very hard technical problem and there is basically no money in it. Business value maybe, but it would need people and companies to collaborate, it would probably need committee level decisions, and so far, nobody wanted to deal with this.

Or at least that's my theory.

EDIT Maybe dat:// will eventually become a viable option, and with that, due to the distributed nature, this kind of DDOS protection is sort of built in.

Re: Cloudflare Network Performance Issues

#263

Post by dboreham »

kortilla wrote: post #261
btown wrote: post #252

Earlier quoted context omitted.

This doesn't surprise me at all - SLA's are widely overrated. No SLA will cover damages incurred by lost business due to an outage. What you likely want is some kind of third-party insurance for downtime caused by outages out of your control - but I'm not even sure this exists.

I guess you’ve never worked in enterprise. SLAs for critical systems very frequently incur payback in excess of the billing on outages.

But not consequential losses which is what the parent mentions.

Re: Cloudflare Network Performance Issues

#265

Post by bowmessage »

morpheuskafka wrote: post #37
jason_zig wrote: post #24

So what should the ideal redundancy plan be here? If you can't log into the CDN provider and they are down do you you just have a second one ready (and paid for) and then log into your registrar and be ready to switch to that secondary CDN provider in this scenario? Or is there some sort of load balancing / routing solution between CDN's that I don't know about / understand?

If you use Cloudflare nameservers, you have to change to new nameservers, wait for that to propogate, and then wait for clients cached records TTLs to expire. So it will be a major disruption no matter what you do.

Can you use your own nameservers that delegate to cloudflare or akami 50% each, then adjust? Is there a service more suited for this than r53?

Re: Cloudflare Network Performance Issues

#266

Post by qiller »

antsar wrote: post #251
Scirra_Tom wrote: post #167

Earlier quoted context omitted.

No good if your Registrar (Namecheap) is behind CF as well!

That would seem like a solid reason to avoid Namecheap. Edit: Wait, do they use Cloudflare? $ dig namecheap.com +short 198.54.117.250 whois: CIDR: 198.54.112.0/20 NetName: NAMEC-4 Organization: Namecheap, Inc. (NAMEC-4) Updated: 2015-11-13 https://whois.arin.net/rest/net/NET-198-54-112-0-1.html

I've got Cloudflare captcha just yesterday when logging in to Namecheap

Re: Cloudflare Network Performance Issues

#267

Post by grenoire »

btown wrote: post #192
Heliosmaster wrote: post #175

Earlier quoted context omitted.

Are you sure it wasn't cached? For us it was showing correctly the incident...

If cloudflarestatus.com isn't serving text content as Cache-Control: no-cache, that's itself an egregious bug.

It serves Cache-Control: max-age=0, private, must-revalidate. Same thing as far as I get it, maybe wider support.

Re: Cloudflare Network Performance Issues

#268

Post by LinuxBender »

LeonM wrote: post #120
aeonflux wrote: post #89

Earlier quoted context omitted.

No, dns doesn't work like this, you can't have backup records.

Not necessarily backup records, but you can add multiple A/AAAA records. There is no guaranteed order though. It is possible to have multiple A/AAAA records pointing to different loadbalancers, but I don't know how browsers would deal with this.

Browsers would deal with it just fine (assuming the site is down hard and not responding with errors). Its some of the API tools and old libraries that may not. They would need retry logic that mimics the browser cycling through multiple A records. OTOH, API tools that have retry logic would just keep trying until the errors clear up. A browser will stop retrying when something responds unless there was javascript running in memory that had retry logic.

If there are errors, the site would need to be modified to not respond if broken and unable to proxy to a working origin. Perhaps CF have not coded their proxies in this manor.

Re: Cloudflare Network Performance Issues

#270

Post by manigandham »

lkbm wrote: post #142
pmlnr wrote: post #72

Good. I'm tired of people not learning that trusting a single gateway with 50% of the internet is bad. Yes, I know, free DDOS protection. There has to be another way of doing this, some mesh based DDOS protection or so.

This seems like a case for putting more of the internet through a single gateway. Having my downtime correlated with everyone else's means users will be more forgiving because they'll perceive it as "the Internet's down" rather than "lkbm's site is broken". (We saw this with CloudFlare. Some users were pissed, and others jumped in with "it's not their fault; AWS is down". That doesn't happen when our stuff specifical…

That's a strange perspective. Users only care that a service works and there is a long history of them blaming whatever is most visible.

If you're site is down, it's your fault in their eyes, not some core infrastructure provider.

Post reply on HN