The race is on to get tickets to the 2012 Summer Olympics in London, England. Millions of people (some 2.3 to 2.7 million signed up to request tickets so far) are clamoring to attend events featuring the likes of Michael Phelps, Ian Thorpe, and Usain Bolt. To distribute the load in the initial ticket request phase, Olympic organizers are using a batch system to accept requests over a six week period. Even with this even-handed approach, the servers were under tremendous load in the early hours of this past Tuesday. We investigate and show how performance could be improved.
Tickets for the 2012 London Summer Olympics went on sale Tuesday March 15. In the UK, registered residents can buy tickets from the official London2012.com website, while those in the US, Australia and some other countries use CoSport.com as their official ticket reseller. With millions of fans are looking for tickets are the servers up to the task?
Unlike the future live ticket phases in June and December this initial request phase is a batch, where the millions of people who signed up enter their event choices from March 15 to April 26, 2011. After all the requests are in, tickets will be assigned, with oversubscribed events chosen by random lottery. Ticket requests during this phase receive the same priority, there is no advantage to applying early. Despite this approach, the sites dispensing tickets experienced high loads Tuesday morning. Checking the official London2012.com site in the morning, it was up and running (see Figure 1):
While the authorized US ticket reseller CoSport had some trouble handling the load (see Figure 2):
Emails to Cosport were promptly returned, and a notice went up saying "Site Offline" it is being updated, come back mid-afternoon (see Figure 3).
True to their word as of 4pm EST the site was up and able to take ticket requests (see Figure 4).
Let's take a brief look at the two home pages using the YSlow and Page Speed tools. YSlow finds both home pages get a grade of C. The CoSport home page is 504.9K in total size, and uses 36 HTTP requests (see Figure 5).
The official London2012.com site also scores a C in YSlow, with 1069K total page size, requiring 100 requests (see Figure 6).
A Page Speed analysis of the two home pages tells a similar story. The CoSport.com home page scores an 80 out of 100 possible points (see Figure 7).
While the London2012.com home page scores a 70 out of 100 with Page Speed (see Figure 8).
Looking at waterfall graphs can help isolate problem areas in web page performance. Using webpagetest.org, we find the following results for both sites. First the overall results for CoSport.com (see Figure 9).
CoSport.com loads in 5.4 seconds, and starts to render content in 2.58 seconds.
The London2012.com site loads in 9.7 seconds, and starts to render content in 4.2 seconds (see Figure 10).
The waterfall graph for the two sites shows how each web page component loads, and breaks down the different load time components (DNS lookup, time to first byte, content download, etc.). Figure 11 shows the CoSport.com waterfall graph.
Note the highlighted areas. CoSport.com redirects to a secure page on the home page, with associated SSL delays. Multiple CSS and JavaScript files delay the time to first byte.
The waterfall graph for the London2012.com is shown in Figure 12. The London2012 site shows about a 0.8 second time to first byte for the home page, and multiple CSS and JavaScript files which delay the time that useful content displays.
The CoSport.com home page is less than half the size of the London2012.com home page (504.9K versus 1069K), and uses nearly 1/3 of the requests (38 versus 100). The front-end engineers at CoSport have done a good job of making their site smaller and more streamlined than the official London2012 site. So even though the CoSport home page is half the size with nearly 1/3 the requests, the London2012 site stayed up and available during the crush of visitors Tuesday morning. This shows that the backend capacity is higher on the London2012.com site. According to Steve Souders, 80% of performance problems are on the front-end (Higher Performance Web Sites, O'Reilly), but under high load the main difference here is the back-end performance and request capacity of the servers.
Based on the findings above, we'd recommend that CoSport.com beef up their back-end infrastructure and CDN to better handle more simultaneous requests and higher peak bandwidth. They could combine CSS files and JavaScript files to minimize HTTP requests, and avoid a redirect to an SSL page on their home page to avoid SSL overhead. During peak access times, they could replace key pages with minimalist pages by substituting CSS text or sprites for graphic text (see the highlighted country button examples above in Figure 4), to minimize the number of requests served. The London2012.com team could improve performance by adding GZIP compression, improving caching, minifying and combining JavaScript and CSS, and optimizing and combining images.
By website optimization on 18 Mar 2011 PM