The biggest thing that companies miss when they're building SaaS applications is that the network fucking matters. I'm talking from a internet-connectivity perspective. The view here is that you can take any ol' 'enterprise' ISP and put your servers on it, and you'll be good to go.
Unfortunately, no two ISPs are equal, which often times, forces you to purchase from both. TCP implementations of OS's today have been tuned for the late 90s, which requires dives under the hood to tune them for today's TCP.
When your application performance is pegged on the network the, most people say just put static content on a CDN - and that works. But for dynamic content, most people think you're screwed. While you can't main any gigantic gains on it, there are a few things you can do for speed: TCP tuning, compression, path optimization, and pipelining.
> TCP implementations of OS's today have been tuned for the late 90s,
Here's where you need to slow down and think for a moment before you re-invent TCP.
If you "retune" everything for broadband, you're crippling your ability to reach your emerging mobile audience, whose TCP metrics look for all the world like dial up and ISDN of the late 90s.
Was in ISP business since early 90s, and in streaming business since before broadband, so familiar with connection profiles, latency, and effects of tuning TCP. There's a lot of lost or forgotten art being reinvented or rediscovered for today's mobile.
We've built an app that dynamically generates images and serves them up inside of emails. People skim through emails pretty quickly so it's important that the images load as quickly as possible. And we usually can't use a CDN since the images are often personalized for each user. The images vary in size, but for the smaller images I'd like to see if slow-start tuning could help.
We disabled Cloudflare after a month because of their awful nLayer routing. We were getting complaints of slow accesses from Telia customers in Europe. Now we're back with SSD Nodes and much happier with SoftLayer's peering and transit connections (they peer directly with Telia).
Most large players in heavy load content ( like live video streaming ) run double failover systems these days. Even if your running systems on S3 piping it through Akamai, you can't guarantee that they won't drop you when your load gets too high. So you have to setup a sister chain going through another origin and cdn.
But even at that if you start talking 100k+ clients you can't offload them all at the same time so you end up having to create this custom origin/mid tier distribution system...
Very annoying. I'd like to see CDN's being held liable if they go down or drop you entirely.
I'm not aware of any real CDNs dropping someone for "load getting too high". Also, for a real CDN, 100k+ clients isn't noticeable.
If you're talking about the "unlimited traffic" or "price too good to be true" commodity delivery resellers, their business models are sometimes built on overselling and like a cell provider, those will throttle or drop you.
That said, a "network of networks" is a great strategy beyond a certain level of traffic. Nine Systems built a great business on that principle for video streaming until purchased by Akamai. Balancing video over multiple CDNs is a service we offer as well.
Finally, if your CDN SLA doesn't hold the CDN liable for going down, you're doing it wrong.
I trid out CloudFlare for a few months for a couple of my sites. I was primarily interested in their 'no downtime' feature but could never get it to work for me. I ended up swtiching to S3 and CloudFront, paying a little each month but it actually works.
Now I know where those annoying challenge pages come from. Was planning to add CloudFlare to my site but if it comes with those challenge pages, I'd rather pass.
i contacted them after seeing that page a couple of times and got a reply saying they had been having some false positives; i've not seen it since. so if you only saw them in the last week or two, and not in the last few days, then it may be something that has been fixed.
Challenge pages cannot be totally disabled. From CF's admin page:
Adjust your basic security level to modify CloudFlare's protection behavior. A low security setting will challenge only the most threatening visitors. A high security setting will challenge all visitors that have exhibited threatening behavior within the last 14 days. Essentially off will act only against the most grievous offenders. We recommend starting out at medium.
Unfortunately, no two ISPs are equal, which often times, forces you to purchase from both. TCP implementations of OS's today have been tuned for the late 90s, which requires dives under the hood to tune them for today's TCP.
When your application performance is pegged on the network the, most people say just put static content on a CDN - and that works. But for dynamic content, most people think you're screwed. While you can't main any gigantic gains on it, there are a few things you can do for speed: TCP tuning, compression, path optimization, and pipelining.