Apple live stream

The live broadcast of the presentation of the iPhone 6 and Apple Watch from the very beginning did not work. Many users, including me, had problems viewing it. At first, I sinned for problems with the Akamai cloud service , but researching the Apple site page showed that most of the problems were due to how they set up Amazon S3 and some other elements of the site.

Unlike the previous live broadcast, this time they decided using JSON to add interactivity to the page, and show 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 is confusing JSON and Ajax) the site has ceased to be cached. Typically, Apple uses Akamai’s caching for such broadcasts, but this time it wasn’t possible to cache the page, which led to a severe drawdown in page loading speeds and display of the video stream. And since Apple inserted the video into the page, the page brakes led to the video brakes. Akamai did not want to comment on this problem, but judging by the code of the page, they still could not cache it. Because of this, Safari also fell when I tried to open the presentation page on the iPad.

Because of all these page updates, the player had to artificially lower the video quality because there were too many requests on the server side. In addition, Apple made a mistake and broadcast through Akamai the video with the wrong sound track, so the first 27 minutes of the video was in a foreign language (for the author of the article). Someone from Apple made the wrong video, and besides, they still had audio and picture out of sync. In addition, it seems to me that I seized the moment when Apple had to restart the server that encoded the video once, after the presentation began - because of this, errors such as “I can’t download the video” and “no access right” got out.

By examining the page metadata, you can determine that Apple hosts the Amazon S3 cloud service. Apparently, Apple posted content in one bucket, with almost no margin for load growth, and it was configured incorrectly. Amazon did not comment on this issue, but it is clear that Apple incorrectly configured the S3 storage, as a result of which they experienced performance problems, as all requests went to one location.

Akamai were the only CDNused by Apple. This is shown by traceroute from different points of the planet. And since they did not have the ability to cache the broadcast page, its performance dropped dramatically. If it is not possible to cache the page on the peripheral server of the cloud service, all requests are sent to the central server, because of which the whole meaning of the distributed network is lost. The graph below, received from a third-party Cedexis service, shows a decrease in the availability of Akamai servers in Western Europe from 100% to 96.5% during the broadcast.



According to the data obtained from various data sources, at the peak, the broadcast of the video presentation occupied a channel of 6-8 Tbps. For comparison, the World Cup broadcast was at the peak of 6.8 Tbps. So no extraordinary load CDN did not experience.

Bottom line: video encoding, broadcasting, javascript, video player, the only server on S3 and constant page refreshes and led to numerous presentation problems. It would be possible to blame everything on the CDN, but apparently, this was not the main reason - it was just that the action was poorly planned and carried out.