tag:blogger.com,1999:blog-342295268741167565.post1816934581671337310..comments2024-02-04T09:42:01.747-05:00Comments on Because .com Wasn't Available: Measuring CDN Performance With Real UsersJonathan Kleinhttp://www.blogger.com/profile/14232876592080837327noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-342295268741167565.post-45276354271971008502013-03-01T16:25:44.656-05:002013-03-01T16:25:44.656-05:00I've never done a thorough analysis of video d...I've never done a thorough analysis of video delivery through CDNs, but from what I understand the main value add there is that they can handle the traffic for you, thus preventing you from needing to have a huge amount of bandwidth to your origin. Getting your content closer to your end users is less important for videos, since you only pay the latency cost once, at the beginning of the connection. Once the data is in flight the latency is largely meaningless. This applies to all large files - bandwidth is more important than latency when you are dealing with a single massive file. Jonathan Kleinhttps://www.blogger.com/profile/14232876592080837327noreply@blogger.comtag:blogger.com,1999:blog-342295268741167565.post-56569510708160057262013-03-01T09:57:28.955-05:002013-03-01T09:57:28.955-05:00Really interesting article Jonathan. I'd be in...Really interesting article Jonathan. I'd be interested to know what you thought a similar analysis of Video delivery by CDN might throw up. I'm currently trying to set up a video on demand site (on a shoestring!) We have spoken to several CDN's and have been given a great offer but have not yet signed. If what your analysis has shown also applies to Video delivery then I would probably be wasting money until we got into serious bandwidth issues some time after launch. Many thanks - Looking forward to reading many more of your blog posts<br />Richard Gammons, CMor.tv LtdRichuk7https://www.blogger.com/profile/05696331301695918073noreply@blogger.comtag:blogger.com,1999:blog-342295268741167565.post-29193548901702337082012-12-18T17:28:46.507-05:002012-12-18T17:28:46.507-05:00This will add to my seo terminology knowledge now....This will add to my <a href="http://www.organicseo.org/book/glossary" rel="nofollow">seo terminology</a> knowledge now. It'll add to the seo info too.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-342295268741167565.post-28295097583645924262012-07-23T15:21:50.056-04:002012-07-23T15:21:50.056-04:00Certainly the 10s download of 200k indicates somet...Certainly the 10s download of 200k indicates something wrong.<br /><br />For CDN configurations in which *that* is not happening, your results are still common for small sites where the CDN often doesn't have the content cached in most of their POPs, and when most of your traffic is in the same country you're in.<br /><br />If you care about latency for people across the globe, that too adds a tick in the CDN's column.<br /><br />But generally they don't add value until you have enough transfer that bandwidth limits are a consideration, that traffic spikes are a consideration, that global latency is interesting, and that POPs generally have hot content cached all the time.Jason Cohenhttps://www.blogger.com/profile/18019929086510000182noreply@blogger.comtag:blogger.com,1999:blog-342295268741167565.post-85924425189094905962012-07-20T18:07:59.732-04:002012-07-20T18:07:59.732-04:00I'd love to get a packet capture of regular us...I'd love to get a packet capture of regular user in US trying to open the site via Akamai... <br /><br />I saw a situation where (at least in WPT) a particular CDN was 2 times slower than all other CDNs for a particular site. In the case of WPT it was loads of re-transmits due to buffer bloat. I could not re-produce this on servers I have access to. The page in question seems to be similar to yours. Domain sharding + few large images.<br /><br />I think that Akamai (or atleast your accounts configuration) is causing re-transmits.sajalhttps://www.blogger.com/profile/10647930314649117946noreply@blogger.comtag:blogger.com,1999:blog-342295268741167565.post-67029723762429650272012-07-20T16:33:55.589-04:002012-07-20T16:33:55.589-04:00Thanks for the feedback Steve! I'll reach out...Thanks for the feedback Steve! I'll reach out to Akamai and see if they have any ideas about why the download is taking so long. <br /><br />I will also pass the image pre-fetching suggesting on to our Frontend Engineering team. <br /><br />Cheers,<br /><br />JonathanJonathan Kleinhttps://www.blogger.com/profile/14232876592080837327noreply@blogger.comtag:blogger.com,1999:blog-342295268741167565.post-61936567458620154932012-07-20T16:15:46.255-04:002012-07-20T16:15:46.255-04:00Great write-up and interesting topic. There are nu...Great write-up and interesting topic. There are numerous performance best practices. Not all of them apply to every site. But that doesn't mean the best practice is bad - it just might not be relevant at that time for that particular site.<br /><br />I analyzed http://www.wayfair.com/ and expected to see some other issue (e.g, blocking JavaScript, daisy-chained stylesheets) on the critical path making CDN performance a lesser issue. But instead the page's onload event is blocked by images - this is rare. <br /><br />There are 5 images each over 200K. That's big, but not outlandish. What's strange is that they are served via Akamai but take 5-10 seconds to download. That's really slow!<br /><br />I ran this in WPT on IE9 from San Jose and DC: http://www.webpagetest.org/result/120720_RX_S87/ http://www.webpagetest.org/result/120720_8E_S2Z/<br /><br />It makes me think something is wrong with Akamai - that's way too long. It appears that it hit appropriate Akamai edge servers (DC hit an Akamai server in VA, San Jose hit an Akamai server in CA). My suggestions: 1. Figure out why it takes 10 seconds to download 200K from Akamai. 2. Try downloading those large images first rather than in the middle. Eg, if you know the images that are going to be needed later start them downloading using JS at the top of HEAD.Steve Soudershttps://www.blogger.com/profile/07051900511910570322noreply@blogger.com