The opening of Aarhus in 2017
Aarhus was probably the busiest it has ever been on the other end of Saturday 21 January, as celebrations for being the European Capital of Culture in 2017 were kicked off with a bang. Novicell had been developing a new website and app for Aarhus in 2017, and in the opening weekend, these were both put to the test.
To cope with the expected heavy traffic at the opening of Aarhus in 2017, Novicell had to make the appropriate preparations. It is important to prepare and be on hand so that technical issues can be resolved immediately and ensure smooth functionality of the website.
A key aspect of preparation was to use a Content Delivery Network (CDN). A CDN is best described as a shield that is set up in front of the original site. When the sudden surge in visitors hit the shield, they see a copy of the original site to speed up the delivery of content. We used a CDN called Fastly.
The setup is relatively straightforward and operates using a Domain Name Server (DNS) which sends traffic through to Fastly's servers. Since the visitor to the website sees a copy, it is imperative that you do not copy the dynamic content to Fastly's shield servers. Therefore, we decided not to move the entire site and made an assessment with the customer to decide which elements which would be static on the days before the opening and, these were transferred to Fastly’s cache.
This method worked as intended as figures for the opening weekend show that Novicell delivered about 70 GB of data to users while Fastly took on about 500 GB of data!
The core of the new digital platform has more than 700 unique events spread throughout the year and in East Jutland. The events can be filtered according to the user’s preferences and offer everything from light installations to dark dining, children's events to rock concerts and more.
The programmes engine retrieves information from the website, app and external partners' platforms and lists the many events that were not cached in Fastly. In the opening weekend, it meant that there were many concurrent requests to the Application Programming Interface (API), and it was not programmed to receive such substantial amounts of traffic. The exact number of requests from images, pages and files amounted to 13200000 requests during Saturday!
The busiest period was Saturday night where there were 2,450 requests every second, resulting in the server struggling to keep up. The pages generating the most traffic according to Google Analytics were the homepage and the event information page.
The overwhelming traffic had two unfortunate consequences: The first being that the website was briefly down due to the many queries. Secondly, there were more than 12,000 downloads for the app during the opening weekend alone which also caused problems for the server. If the app had been launched on time, this issue could have averted. This is something we will learn from.
The app launched on a Friday afternoon while there was much traffic on one of the external partner’s website. This meant that we were not entirely prepared and there was a need for additional caching. We, therefore, took a copy of the entire API output to the app, which we fed to a static file that queries could draw on. That way we did not load the server with many requests.
The next thing we did was use a proxy server to implement a load balancing setup, where traffic was distributed on multiple servers in a Web Farm. This enabled the website to handle up to ten times as many concurrent visitors. We decided to look at the figures during the day, and there was a point where 4100 were using the app simultaneously.
Using a proxy server meant that even if the site was forced to its knees, some users still hit the right site, while the others landed on the fall-back page. Although this is not the goal for the user, it is still a solution to the problem as it provides the user with a result and alternative rather than receiving an error page. This is necessary for the user's overall experience.
Five recommendations for managing traffic peaks
Here are five tips that are useful for applications that may be subject to high traffic e.g. Black Friday sales or anything in conjunction with the launch of a product etc.
- Have a clear strategy for your solution's performance, and be sure to consult with someone who has experience dealing with traffic peaks.
- Run multiple stress tests on your solution so that you can understand exactly how it performs and reacts high traffic inflows. You can use tools like Blitz.
- Be sure to introduce your different platforms before your estimated peak. If for example, you can spread the downloads of the app and content out over a longer period, you can minimise the risk of overloading the server.
- Consider where your traffic is coming from. Many third-party channels can broadcast traffic in your direction, for example, publicity on TV or the big external sites. It can also be an open API that is called from partners or applications.
- Monitor your setup. A modern website consists of many components, and when there are many visitors, it can be difficult to determine which components are having the most difficulty, but detailed monitoring is essential to keep up with high surges in traffic.
Both the customer and ourselves have learned a lot from the opening weekend of Aarhus 2017. Now we look forward to many exciting cultural events throughout the year as well as new initiatives for applications and websites.