Digging Deeper Into The Cloudflare CDN(zingcheckout.com)
zingcheckout.com
Digging Deeper Into The Cloudflare CDN
http://www.zingcheckout.com/blog/2012/2/4/digging-deeper-into-the-cloudflare-cdn/
19 comments
> 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.
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.
Actually they don't. Dial-up is low bandwidth, low latency. Mobile is high bandwidth, high latency.
Dial up is low latency when a modem adds 200 ms by itself?
Mobile is high bandwidth when an EDGE connection might pull 110 Kbps when the rural user is lucky?
Either you're confused, or talking about different tech.
Mobile is high bandwidth when an EDGE connection might pull 110 Kbps when the rural user is lucky?
Either you're confused, or talking about different tech.
Dial up is low latency when a modem adds 200 ms by itself?
Closer to 100ms and, more importantly, constant not variable.
Mobile is high bandwidth when an EDGE connection might pull 110 Kbps when the rural user is lucky?
The fastest modems sold were 56kbps.
Closer to 100ms and, more importantly, constant not variable.
Mobile is high bandwidth when an EDGE connection might pull 110 Kbps when the rural user is lucky?
The fastest modems sold were 56kbps.
I had ISDN in the 90s, at dual 64k.
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.
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.
Are there any up-to-date resources you could recommend for TCP tuning?
I would look at Google's papers regarding TCP tuning mostly. They're very well written with some real-world data.
What kind of applications are you creating?
What kind of applications are you creating?
Thanks! I'll check those out.
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.
This is our service: http://movableink.com
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.
This is our service: http://movableink.com
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).
Your mileage may vary.
Your mileage may vary.
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.
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.
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.
In video-streaming 100k+ clients equates to 25+ GBit/s. Yes, that is noticable, even for a "real CDN".
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.
Their no down time feature is just them holding a cache'd copy of your site. It could technically not work for you and still work for someone else.
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.
i believe those are optional
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.
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.