BlazeMeter Helps New Social Platform for Flyers Get off The Ground
This is a guest post written by Russell Hyer, the CTO at Airclandestino - an innovative social platform for travelers.
Three weeks ago we launched Airclandestino, a new social platform that allows travelers to get in touch with fellow passengers before they even board the flight. By making this initial virtual connection, travellers can arrange to share taxis once they’ve landed or even share tips and information about their chosen destinations.
To use our platform, travelers from across the globe must log onto our site to connect with each other. So, before we could even make this vision a reality, we needed to make sure that our site was functional and would be able to cope with the load.
My first key challenge was translating all the flowcharts, diagrams and graphics into functional code that would display correctly across multiple browsers and systems. Unfortunately, there was no shortcut here - just five months of months of very hard work, writing code on pieces of paper then back into my laptop and retesting. Of course, version changes during our testing phase complicated this procedure so this stage of work had multiple loops. The key insight, then, was writing the interface using pure HTML5 and CSS as much as possible, so that a version on one system would easily transfer to a browser on another (so long as this was a modern enough browser).
As we got closer to our launch date, the necessity of ensuring our site could cope with very large system loads became more apparent. Before we could consider launching the site, I needed to be confident that we could support 1,000 concurrent users without too many latency issues. If we couldn’t support at least this many users, our new users wouldn’t be able to connect with each other and they would quickly lose patience with the site. At this point, we decided to turn to BlazeMeter as it offered us a very quick and easy way to start running performance tests on our website.
Pre-Launch Load Testing
As Donald Knuth put it: “Premature optimization is the root of all evil (or at least most of it) in programming.” I certainly found this to be true here. We had some versions which utilized super optimized web server software, but were slightly more unstable. Through testing, we were only able to see marginal differences between these super optimized versions and the regular ones. So we decided to put the unstable versions aside and concentrate on the more stable ones. The optimized ones were more unstable at the systems or OS level, but very stable once they were running. Getting all systems to speak to each other (so that database, content etc. was accessible) required some minor stitching together of systems via the modern equivalent of superglue: a shell script. As such, I wasn’t confident about launching with this configuration.
BlazeMeter really helped us manage a predictive launch scenario when planning for large loads. It was fantastic to be able to run tests with multiple users at once on the site. However, the interpretation of problems was still a big challenge for us. In our site, we have many dynamic parts that aren’t so easy to test and, as such, we have had to create theories about their behaviour at different scales.
For example: an earlier version of the site extracted an image directly from the database and then output it in a massive file for the client to download all at once. Through testing, I was able to recognize that there was a problem and then theorize as to the root cause of the issue. Once I understood the underlying issue, I could easily correct the flaw by separating the output of images and text - making the service faster and even more responsive. Since launching the site, I’ve also been able to use caching to reduce load on the systems that I witnessed in testing.
Our pre-launch testing took a total of two months. As we rigorously load tested different versions of the site before the launch date, we knew that we’d be safe for at least 1,000 concurrent users - and I also built in procedures to upgrade performance if the figure rose above that number. To do this, I set up redundant database servers that can be grown on demand along with web servers. Performance can be grown rapidly to match demand - without the need to change even one line of code in our production systems.
The launch day went without a hitch, and I later made some minor changes to the cache settings to increase performance. We’re now gearing up to launch the mobile apps as soon as we finish the development and testing phases.
Need some help with your load testing? Check out our educational resource center