Sep 19, 2023
Sep 19, 2023|
7 min read
Explore how we collaborated with Previon Plus to ensure optimal user experience and site performance for Züri Fäscht, Switzerland's largest festival. Learn how meticulous preparation and focus on the application and hosting, including the Content Delivery Network (CDN), contributed to the event's success.
Websites created for large events differ notably from standard corporate sites, as they must handle sudden, high-traffic surges from thousands of simultaneous visitors during an event. Such event sites must prioritize optimal user experience during the expected high-traffic period. They are more likely to be successful if a well-prepared team works together to optimize the user experience accordingly.
We did precisely that with our partner, Previon Plus, for the Züri Fäscht website. The Züri Fäscht is the largest festival in Switzerland and takes place every three years, with this year’s event running from July 7th to the 9th. Around two million visitors visit the city of Zurich during this three-day event. The Züri Fäscht website's primary purpose is to inform visitors about what is happening during that time, enabling them to bookmark the many events, food options, and activities they plan to visit during the three-day festival.
For this to be successful on and during the event days and for the website to perform optimally, close collaboration and meticulous preparation are crucial. Our preparation started five months before the festival, with meetings focusing on aligning the Previon and amazee.io teams on the tasks and objectives. Together, we focused on two main areas to maintain site reliability, performance, and uptime:
1) The application
2) The hosting, with a focus on the Content Delivery Network (CDN)
For the next step, we tackled the website hosting challenge. The critical part here was ensuring that the workload generated by visitors on the website remained manageable on our infrastructure. Our solution was to use a Content Delivery Network (CDN) to serve the content to users, thus leveraging the efficiency of such a hub. As the Züri Fäscht Drupal site was designed explicitly for making use of a CDN, we preinstalled the following modules:
The Fastly module connects the Drupal site to the CDN we use at amazee.io. The basic configurations, such as the Fastly Service ID and parameters necessary for DNS handling on our Platform, are set on this module.
The cache headers must be set on every site for the CDN to know what can be cached and how long. This module provides granular control of Drupal’s cache control headers.
If the content on the site is updated or deleted, the CDN needs to be updated accordingly. The purge module ensures that old content is cleared or updated accordingly.
While the Drupal modules were part of the application and thus handled by Previon, our CDN specialists had to ensure that the Fastly CDN Service was configured and set up correctly for the circumstances. Our standard operation model updated the services automatically via our configuration management. But a special event like this meant optimizing and fine-tuning the caching abilities. Two metrics were critical for the successful caching:
Our many years of Drupal hosting experience formed the basis of our CDN configuration, which we set up to withstand the expected traffic load without breaking a sweat.
“A certain tension on my side to have the website available for the approximately 2 million visitors at all times was naturally present. Therefore, the professional exchange and optimization of the platform in cooperation with amazee.io was central and worked perfectly. So once again, it has been shown what a competent and reliable partner we have in amazee.io.”
– Thomas Werthmüller, Head of Technology, Previon Plus AG
The traffic gradually increased consistently in the days leading up to the festival. This helped us to get an idea regarding the traffic patterns and user behavior that we could expect.
We encountered an attack on our systems three days before the event. This attack generated 1.4 Million hits in 40 seconds. That was a large number of requests in a very short time and certainly more than we would have expected in 40 seconds on a festival day. Although the intention behind the attack was undoubtedly nefarious, it certainly boosted our confidence in the technology used and our rulesets that apply automatically in such cases. It also challenged us to find additional system and platform optimizations.
Our team put some finishing touches on the CDN configuration the evening before the event. We also submitted the findings to Previon that evening. The final CDN configuration was applied at 11:00 AM on the festival's first day. As a result, the cache coverage increased far above 99%, which is near perfect. Additionally, Previon deployed their last changes to the applications at noon, when there were already significantly higher traffic volumes. These last deployments were the last changes we implemented. However, this did not mean we did not closely monitor the developments and happenings in the back end.
As shown in graph 1) above, the traffic increases consistently over seven days. Also, you will notice the spike in traffic on the evening of July 4th (the unsuccessful attack) and our last change to the CDN config (below, the black line around noon of July 7th).
Looking at the timeline of the festival itself (see graph 2) above), we see a very typical user behavior pattern. Traffic starts picking up in the morning, with a peak around Lunchtime (10:00 AM in the graphs). A second peak is reached in the late afternoon when visitors are figuring out their plans for the evening. The last peaks were around 10:00 PM, when the users were most likely looking for what parties to attend.
The hit ratio was another critical metric for gauging the site's stability. There are no definite benchmarks for how high a “good” hit ratio is. A widely accepted statement is that everything above 90% is considered good. Thus, the hit ratio of 96.64% over the duration of the event was more than satisfactory.
The last critical metric we monitored throughout the festivities was the cache coverage. To push this metric above the 99% mark, we had to rely on the traffic numbers the day before the event. As the primary purpose of the website was to provide information (for planning the visit), we could forecast that the sites visited most right before the event would be the ones to receive the highest traffic volumes during the event. We shared our findings with Previon on the evening before the event so they could improve the identified sites accordingly. Working hand in hand resulted in a small but significant difference in the cache coverage around noon on the event day, pushing said cache coverage from around 95% to 99% (as seen in graph 3) below).
Our meticulous preparation paid off. During the event, we could relax and enjoy the festival while closely monitoring the above metrics and the site.
“Successful, highly scalable projects need several teams to work together, from the hosting provider to the agency that builds the website. Leading up to the high-traffic event, we had several meetings and rounds of improvements where we put together our findings to ensure smooth sailing. We focused on keeping communication methods short during the event, conveying what we saw “in the engine room” to the agency, and implementing improvements or changes if needed.”
– Bastian Widmer, Platform Lead, amazee.io
Having and then keeping the key metrics at a very high level resulted in a minimal workload on our infrastructure clusters. Thus, although we built the clusters to scale rapidly on demand, we did not have to put them to the test.
In summary - We advise ensuring the following steps are applied and optimized for high-traffic website events:
If you’re interested in learning how amazee.io’s ZeroOps application delivery platform could help solve your technology challenges and achieve your strategic goals, 🗓️ schedule your free technical demo today.