i find the edgecast thing may actually be a backhaul issue for cache misses from the origin site, as i found a few more things, and some things were downloading at like 80 to 200k/sec.
probably similar issue with dl.google.com.
also edgecast seem to have a whole lot of their content only in the US, not that it probably matters too much.
RalphFromSnap: Good news everybody, our 10Gbit peering session with Edgecast in Sydney has just gone live (well, @ 2am).
Can you guys do some more testing for us during peak hours and let us know if you're seeing any improvement?
Cheers, Ralph.
unfortunately think it's a backhaul issue from the edgecast node to the origin site, i'd just tested before, and it was going fast when doing a second download of exactly the same file.
https://wiki.gogrid.com/wiki/index.php/GoGrid_CDN
from here i tried the 10mb file and got it to cache. i dunno how to cache bust it. i haven't tried 50mb file so i expect it won't be cached atm.
dunno a good way to look for edgecast large test downloads too.
I emailed support@snap regarding dl.google.com, got a reply this morning saying they made some changes but they may have been confusing the edgecast change with dl.google.com
Anyway the AMD driver comes down a lot better now but drops off towards the end, might be edgecast as mercutio says.
remember when you were doing testing last night would have still been australia peak time.
i think it's probably more complicated than that. it may be a disk bandwidth or such issue, it seems speeds are quick at first, it may have multi-tiered storage or such, and have faster storage for the start of files. (so that most people don't notice performance issues)
noticed that akamai only have gigabit in sydney, so probably aren't really prioritising it as a primary location, they have 40 gigabit in los angeles at any2ix, and 10 gigabit at equinix in los angeles. as well as lots of other states in the US...
probably part of the reason it's slow is too much data to keep on disk, so it keeps having to reget it from the internet.
well JamesL. I've found that both cloudflare and akamai both tend to slow down web sites when used in NZ...
CDN's is a complicated issue.
There's two kinds of caching, push-caching and pull-caching. In push caching when a file is updated all CDN nodes get pushed the updates. In pull caching when a user requests a file it checks to see if it's still current against a master server. If it is, it sends what it already has, if it doesn't then it pulls the request from the master server.
The problem comes from two things - one is that the latency to do the "check" when routing via australia is higher than going direct, and your browser may have the current file already. The second is that some of these CDN's seem to have outdated software/hardware giving below average tcp/ip performance. I expect that's contributing to slow miss speeds for large files like the ATI driver.
Generally speaking push caching is heavily preferred, but is more expensive generally. And works better with fewer locations.
When you have 1000s of locations for caching it only works well if your site is getting a LOT of visitors. For other sites it works better to have fewer destinations so that there's a bigger pool for cache hits, and less wasted space trying to "store the internet"
generally speaking for large file downloads pull caching shouldn't hurt, as long as the file stayed in cache. It'll add a little latency, but shouldn't decrease performance. but for interactive elements push caching will reduce latency and improve performance significantly.
the ati download seems to be using pull caching, but we've managed to reproduce slow downloads multiple times over, suggesting that they haven't got nearly enough storage capacity. it's not just the ati download that suffers from cdn slowness though. if you find international news papers using akamai most of them will give poor performance.
Interesting, thanks for elaborating. I assumed most placed just used pull caching, didn't think about the push caching scenario which seems better but obviously cost prohibitive
JamesL: Interesting, thanks for elaborating. I assumed most placed just used pull caching, didn't think about the push caching scenario which seems better but obviously cost prohibitive
Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly
to your computer or smartphone by using a feed reader.
Trusted
Snap Internet
