Bummer Live Apple

The live broadcast of the presentation of the iPhone 6 and Apple Watch from the very beginning did not work out. Many users, including me, had problems viewing it. At first, I sinned at the problems of the Akamai cloud service, but research on the Apple website page revealed that most of the problems arose because of how they set up Amazon S3 and some other elements of the site.

Unlike the previous live broadcast, this time they decided to add interactivity to the page using JSON and display tweets related to the event at the bottom of the page. As a result, the page was updated several times per second. Because of the decision to use JSON ( approx. Transl. - it seems to me that the author confuses JSON and Ajax ) the site has stopped caching. Typically, Apple uses Akamai caching for such broadcasts, but this time it was impossible to cache the page, which led to a strong sagging of page load rates and display of the video stream. And since Apple inserted the video into the page, the page brakes led to video brakes. Akamai didn’t want to comment on this problem, but judging by the page code, they still wouldn’t be able to cache it. Because of this, Safari was also changing with me when I tried to open a page with a presentation on the iPad.

Because of all these page updates, the player had to artificially underestimate the quality of the video, because there were too many requests on the server side. In addition, Apple made a mistake and broadcast video with the wrong sound track through Akamai, so the first 27 minutes of the video was in a foreign (for the article's author) language. Someone from Apple made a wrong video, besides, they still had out of sync sound and pictures. In addition, it seems to me, I caught the moment when Apple had to restart the server that encoded the video once after the presentation began - because of this, errors like “I can't load the video” and “no access right” got out.
')
By studying the metadata of the page, you can establish that Apple is hosted on the Amazon S3 cloud service. Apparently, Apple placed the content in the same batch , with almost no margin for increasing loads, and it was incorrectly configured. Amazon did not comment on this question, but it is clear that Apple had incorrectly configured the S3 storage, which resulted in problems with speed, because all requests went to the same location.

Akamai was the only CDN used at Apple. This showed traceroute from different points of the planet. And since they did not have the opportunity to cache the broadcast page, its speed dropped dramatically. If the page cannot be cached on the peripheral server of the cloud service, all requests are sent to the central server, due to which the whole point of the distributed network is lost. On the above chart, received from a third-party service Cedexis, you can see a drop in the availability of Akamai servers in Western Europe from 100% to 96.5% during the broadcast.



According to data received from various data sources, the video presentation broadcast took up a 6-8 Tbps channel at the peak. For comparison, the World Cup broadcast took at the peak of 6.8 Tbps. So no extraordinary loads CDN experienced.

The bottom line: video encoding, translation, javascript, video player, a single server on S3 and constant refresh pages and led to numerous presentation problems. It would be possible to blame everything on the CDN, but as you can see, this was not the main reason - just the action was poorly planned and carried out.