We often hear of huge crowds of shoppers thronging their favorite retail outlets on Sale Days like Black Friday, Cyber Monday or for holiday deals. Earlier, this would be people physically jostling each other to gain an entry to the outlet. Today it also means millions of people hitting the online store at the same time to buy the items on sale.

It’s easy to imagine the mayhem such a crowd would cause in a physical store.

Surge in online traffic could cause a similar mayhem as well (if not worse). This is true not just for websites dealing with retail products, but for any tech product that expects traffic dictated by real world interactions.

Prepare for the unexpected

At Zipy, we deal with data at scale. The data we process depends on external factors that are not under our control. Since we could not predict the traffic patterns that we would deal with, it became very important for us to prepare for the unexpected.

Enter the need for Load Testing.

What is load testing really?

In simple terms, load testing is a kind of performance testing where real-world simulations are created to measure and analyze the performance of the product under load. The identification and analysis of bottlenecks under load becomes a key outcome of the process.

What are we looking for in load testing tools?

There are many load testing tools available in the market today. We needed to zero in on a tool that would help us anticipate issues in our product under heavy load and be flexible enough for us to tinker with. Since we’re a growing start-up, we needed a versatile tool that we could continuously build on as we expanded.

When we were taking our decision to choose one among the many tools, this is what we were looking for:

• Simple start with our existing set-up
• Flexibility to add test cases
• Integration support with CI/CD pipelines
• Ability for component testing as well as end to end testing
• Capable of simulating heavy concurrent traffic patterns
• Open source & free with good community support

We chose Gatling, here’s why

Gatling is a very popular open source Load Testing tool for analyzing your product’s performance precisely and identifying its bottlenecks. Now, let’s see how Gatling fit into our scheme of things -

• Simple start: Like many other Load Testing tools, Gatling comes with a built-in script recorder. Getting started with Gatling is as simple as using a HAR file of your webapp interactions to generate a simple simulation that mimics your recorded navigation. Once you are comfortable with using the generated script, you can then tweak it to meet your needs or create new test cases for simulating different scenarios.

• Flexible: Once you get started with basic Gatling scripts, you can write your own test cases in Scala & build your test suite depending on your use case. Gatling comes armed with some very useful inbuilt components that help you create different Scenarios in code. You can make it as basic or as sophisticated as you want.

• Integration with DevOps: Since we wanted to start small yet have the flexibility to grow our Load Testing framework, Gatling’s inbuilt support for integration with CI/CD pipelines made it even more appealing. This is something that we knew we would turn to sooner or later.

• Component Testing as well as End-to-End Testing: While we started using Gatling for testing some of our components and have continued to do so for more than one kind of requirement (more details on this later), we also have had our eye on creating an end-to-end testing system. Gatling with its Functional Specs feature will enable us to do so in the future.

• Heavy concurrent traffic simulation: Gatling does exceptionally well to generate heavy traffic patterns without overwhelming the system on which you run it. We have used Gatling for all kinds of Load Testing - capacity testing, stress testing and soak testing.

• Open source with good community support: Being a startup, we did not want to invest money on a tool specifically for Load Testing. Gatling has a free, open source version with a vibrant community and most importantly, exhaustive documentation. This was vital to us as we were trying to use Gatling to build test cases to meet our specific needs.

One tool, many uses

So now we’ve looked at why Gatling made sense for us. We started using Gatling very early on in our journey. We used it early & we have used it often. In fact, we have used it for cases where we did not envision that we would use a load testing tool.

• Analyzing which component of our pipeline was slowing down on high load
• Edge case packet simulation
• Recreating concurrency issues in our code
• POCs to decide which architectural component is better
• Feature capacity testing
• Performance benchmarking for our DB reads & writes
• API performance testing

What we have discovered along the way is that the only thing that limits your use of a flexible tool like Gatling is your imagination. We do have a lot of other use cases which we would like to explore and build with Gatling as we continue our journey of building our tech product.‍‍