This month, DJ’s Hardwell, Dyro, and Dannic returned from Revealed Recordings’ North American bus tour. These guys have been amazingly successful, scoring high on the music charts. After releasing a number of successful records, they continued last year’s tour, hitting ten of North America’s most prestigious venues.
You can imagine that when you go to one of the concerts of these top DJ’s, you get to experience something special. Their performances are supported by extensive shows, featuring 3D imaging, LED water fountains, and obviously world-class sound systems.
An important aspect of these tours – and an artist’s life in general – is keeping in touch with their fans. Fans now expect an almost 24/7 peek into what is happening on tour, supported with video fragments, social media, and other interesting news. To do this right can be a challenge, the selection of the right infrastructure and the design of a system to handle and scale to millions of visitors is imperative. Cloud and CDN infrastructure is changing the way this is done: so how was this used for the Revealed Tour?
Private Cloud powered by CloudStack
The Revealed on Tour website is managed by a common open-source WordPress CMS. As publishing all content dynamically with the WordPress system itself would not scale, WordPress is used to generate static content – as well as to easily manage graphics and texts. The tour site is essentially a mash up of various services and content types, bringing social media, video, and pictures together in a single experience. WordPress gathers all of this content, and presents it to the front-end servers.
The front-end servers are only serving static content, pre-generated by the Middleman project – a system that generates static websites easily. The back-end server is running WordPress, and JavaScript is used to ‘glue’ this together and create the site structure. The result, together with ‘heavier’ content, is distributed via the Leaseweb CDN. To make sure the CDN can handle the content correctly and efficiently, Middleman optimizes the content for caching and distribution.
For both parts of the infrastructure, Revealed chose to run these in the Leaseweb Private Cloud ( powered by CloudStack). Using this Private Cloud infrastructure has a number of advantages in this scenario:
- Cores are private and reserved. Capacity is guaranteed, always available and reserved.
- Instances can scale in a flexible way. Instances can be assigned additional cores or memory when more capacity is needed.
- When more front-end instances are needed, they can easily be deployed from customized templates, or cloned from an existing instance.
By giving Revealed full control over their private cloud, Revealed could simply scale up when needed, and focus on their core business – making sure the software is running right, and content gets presented to the fans as soon as possible.
Distribution via the Leaseweb CDN
Hardwell, Dyro, and Dannic have many fans who want to follow their tour – which means it is difficult to predict the amount of bandwidth needed to distribute all of the content. Peaks in visitors are also a fact of life, the amount of ‘hits’ on the infrastructure skyrockets after new content has been posted, as well as around important events on the tour. Traditionally, serving this type of traffic requires to simply purchase ‘too much’ bandwidth, potentially losing performance while the connections fill up and you are waiting for an upgrade.
To counter this problem, Revealed chose to connect the front-end servers to the Leaseweb CDN, which removes the problem of having to worry about bandwidth and scaling. To put this into perspective: in about a week’s time, the Leaseweb CDN was closing in on having processed 4 million hits, without breaking a sweat. Integrating the Leaseweb CDN with the Private Cloud infrastructure was easy: visitors connect to a CDN node (which is automatically selected to be closest and best performing), and the CDN pulls all content from the Private Cloud infrastructure. Statistics and visitor counts can be retrieved via the CDN control panel.
To ensure that visitors get new content as soon as possible, the Leaseweb CDN was instructed to cache all content for only one minute. After the content has expired, new content is retrieved from the Private Cloud, and served on to millions of visitors.
After the tour
After the tour finished, Revealed scaled down the infrastructure back to normal levels. The advantage of being able to scale like this, is also a financial one: once the infrastructure and bandwidth is not needed anymore, it can easily be decommissioned. Front-end and back-end cloud infrastructure can be saved in case it is needed for a new tour, and some of the infrastructure can remain online, for fans who want to take another look at the content. Therefore, for now, the Revealed on Tour infrastructure is hibernating and almost free. Luckily, when Hardwell, Dyro, and Dannic come up with new projects – it will be ready to spin up once again.
Products used
In case you would like to read more about the setup – here’s an overview of the technology used:
- Back-end systems: WordPress running on Ubuntu
- Front-end systems: Ubuntu and Nginx. Middleman for generating static content. HAML/SASS for templating and layout, combined with JavaScript/jQuery.
- Compute: Leaseweb Private Cloud powered by CloudStack
- Distribution: Leaseweb CDN
Any questions or feedback? Let us know in the comments!
Lucas Rolff
May 2, 2014 at 16:28Question:
How come, that building a complex system for a simple site happens?
Why would you use some javascript to glue WP and middleman together, why not use one of the good free wordpress plugins that generates static content, and rewrite all requests to the cache folder, this would scale easy to 4k requests per second if just enough bandwidth on the pipe.
What could be done, was to simple put the site directly on the CDN, and every request going to the site would hit CDN directly, instead of a set of cloud servers. This would simplify the setup, as well as lowering the costs of the actual hardware required to have the site online.
Since I can’t access the site, I’m not able to make any calculations, but even a simple VM, with a gigabit connection, a simple WP install, and WP Super Cache plugin.
Let’s say all static content (images, video, css, js) was served using CDN, so the only actual content we would load from the VM would be the HTML itself.
Assuming that the page size would be 15 kilobyte uncompressed, compressing it we could lower it to let’s say 8 kilobyte (not unrealistic)
1 gigabit is 125 megabyte per second, let’s remove some overhead, so 105 megabyte (Large overhead :P)
105 megabyte (assuming 1000 kilobyte per meg) would be 125 requests would consume around 1 megabyte traffic per second.
This means we can multiply this by 105, resulting in 13125 requests per second, and we would be maxed out on the 1 gigabit dedicated connection, just for serving HTML.
Since the site would most likely not peak 13k requests per second, we wouldn’t need that high bandwidth.
WP Super Cache scales easy to 6k requests on a VM with 512 megs of memory and dual core 1.2 ghz CPU running nginx.
So it seems like the setup for this specific site is way too complicated for such a simple thing.
Just my few cents.
Robert van der Meulen • Post Author •
May 5, 2014 at 15:09Thanks Lucas!
Appreciate the comments, and I’ll pass them on to the people who worked on the infrastructure.
I guess in all of these situations there are different ways to get to your goal – I know some of these choices were made based on preference and experience.
Ask 10 engineers (or developers) for a solution, and you’ll often get 10 different ones :)
With regards to the middleman-use: this was chosen to be able to easily use HAML+SASS, and was used to minify static content – and to add hashes to filenames cached by the CDN, making expiring part of the content easier.
Again, i realise there’s multiple (or maybe even better) ways, but in the end, this did the job, and everyone involved was happy with the results. That said, your feedback has been passed on.
Thanks again!
Robert