• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer
Codemotion Magazine

Codemotion Magazine

We code the future. Together

  • Discover
    • Live
    • Tech Communities
    • Hackathons
    • Coding Challenges
    • For Kids
  • Watch
    • Talks
    • Playlists
    • Edu Paths
  • Magazine
    • Backend
    • Frontend
    • AI/ML
    • DevOps
    • Dev Life
    • Soft Skills
    • Infographics
  • Talent
    • Discover Talent
    • Jobs
  • Partners
  • For Companies
Home » Backend » Lessons Learned from Load Testing
Backend

Lessons Learned from Load Testing

In this article we'll learn a bit more about what is load testing, why it is important and which are the best frameworks to use.

October 27, 2020 by Antonio Turibbio Liccardi

developer load testing
Table Of Contents
  1. What is Load Testing and how does it work?
  2. Collect your metrics for load testing
  3. If my system breaks, what can I do?
  4. What are the outcomes?

Load testing is a crucial task for any developer who work on backend services. At Codemotion, we are always interested in providing values for all developers, and that’s one of the reasons why the Spanish edition of the Codemotion Online Tech Conference (3-4-5 November) will cover also these topics (check the agenda and get your free ticket here!)

In 2019, we had the pleasure to have Katie Koschland delivering an interesting talk about load testing during our conference in Rome. She talked about her experience of finding a performance problem on the Financial Times website. Although she and her team didn’t manage to get to the root of the problem, she did learn a few key points that could help anyone in the same situation. In this article, we will try to understand what she faced and what are the outcomes. But first of all, let’s talk about load testing.

What is Load Testing and how does it work?

Load testing is a type of performance test that measures how your system behaves under a high load of users. What is important here is to collect metrics and runtime problems to understand how your system performs and what are its limits to help you do some tweaks. A more advanced type of performance test which usually runs in conjunction with a load test is stress testing, in which the aim is to break your system using predictable or unpredictable scenarios.

performance testing

But how does load testing technically work? It mainly consists of testing a requirement scenario based on a URL address (this could be a website page, a REST API) that is called multiple times simulating user interactions. Indeed, two main requirements for load testing are execution time and the number of concurrent virtual users.

Today there are many frameworks available for load testing. It mainly depends on what are your necessities and how you would like to run this kind of test. Generally, load testing frameworks require some hardware infrastructure, to provide a more realistic testing environment (such as test controllers and many test agents). If you can’t afford it, you can always use a cloud service such as Microsoft Azure Cloud Load Test to provide in no time a ready-to-use infrastructure.

Back to Katie’s situation, the load testing framework used is Artillery, due to its simplicity of installation and use; we just need to install it on a machine using NPM:

npm install -g artillery

With artillery, we can execute a one-shot test, or we can use a YAML script to configure a scenario with one or more specific stages. Here’s an example of a simple script:

In this script, we are testing the website artillery.io using 20 virtual users for 60 seconds. We can run the script using:

artillery run test-site.yml

At the end of the execution, artillery will provide us with a detailed report that can help us to identify bottlenecks and, more generally, any performance issue. Lastly, you can easily integrate such load tests into your delivery pipeline thanks to CI tools flexibility.

Collect your metrics for load testing

load testing metrics

When you load test your application, you need to plan what scenario and amount of load you want to apply to it. Usually, you can define levels of load regarding a number of concurrent virtual users and execution time.

The right way to plan it is to define different phases in which you apply a different amount of load and understand how your system performs.

In Katie’s situation, she defined three different phases:

  1. warm-up: 10 virtual users for 60 seconds;
  2. ramp-up: from 10 to 25 virtual users for 120 seconds;
  3. cruise: 25 virtual users for 1200 seconds.

Also, she did stress testing on her system through the break phase with the following configuration:

  1. crash: 100 virtual users for 30 seconds.

As we said before, the aim of load testing is to collect metrics. Indeed, metrics are the only way to understand what is not performing in your system as well as expected. Depending on the testing framework, you can choose what metrics you want to collect and the level of detail related to them. You can even integrate your reports into your external monitoring systems such as Datadog, Grafana or Telegraph to help you to have a broader view of how your system is performing.

If my system breaks, what can I do?

metrics graph load testing

Load testing also helps you understand what you can do when your system breaks. You need to be prepared for situations in which your application is down and you need to bring it up as soon as possible.

For this reason, you need to have an emergency plan that helps you to:

  1. scale your application when it is under stress;
  2. fallback deploy in case that new features are not performing well.

Also, it’s a good design choice to have a courtesy page, in case your application is having runtime errors.

What are the outcomes?

Katie didn’t succeed in understanding what the problem was in her system. But, in her case, the experience is the first step to learn and improve. She did learn how to manage these kind of situations and most of all collected a set of tools that are her everyday toolbox.

facebooktwitterlinkedinreddit
Share on:facebooktwitterlinkedinreddit

Tagged as:Testing

Why Should You Care to Learn TypeScript?
Previous Post
DEVS FOR HEALTH: a Hackathon for Good
Next Post

Related articles

  • GraphQL Testing With Karate
  • Learning DevOps: What are the Best Online Resources and Tools in 2020?
  • A DevOps Mindset Benefits Many Professions
  • Cloud computing remains a critical component of innovation
  • How to Monitor Google Cloud
  • How to Monitor Microservices
  • What Are the Main Areas of Development for a Data Analyst’s Career?
  • Terraform AWS: Up and Running in 25 Minutes
  • Ready, Steady, Crash! One engineer’s journey into the world of load testing
  • Black Friday: How to Manage Huge Traffic on Your App

Primary Sidebar

Learn new skills for 2023 with our Edu Paths!

Codemotion Edu Paths for 2023

Codemotion Talent · Remote Jobs

Game Server Developer

Whatwapp
Full remote · TypeScript · Kubernetes · SQL

Back-end Developer

Insoore
Full remote · C# · .NET · .NET-Core · Kubernetes · Agile/Scrum

Full Stack Developer

OverIT
Full remote · AngularJS · Hibernate · Oracle-Database · PostgreSQL · ReactJS

Data Engineer

ENGINEERING
Full remote · Amazon-Web-Services · Google-Cloud-Platform · Hadoop · Scala · SQL · Apache-Spark

Latest Articles

Will Low-Code Take Over the World in 2023?

Frontend

Pattern recognition, machine learning, AI algorithm

Pattern Recognition 101: How to Configure Your AI Algorithm With Regular Rules, Events, and Conditions

AI/ML

automotive software

Automotive Software Development: Can Agile and ASPICE Coexist?

DevOps

programming languages, 2023

Which Programming Languages Will Rule 2023?

Infographics

Footer

  • Magazine
  • Events
  • Community
  • Learning
  • Kids
  • How to use our platform
  • Contact us
  • Become a Contributor
  • About Codemotion Magazine
  • How to run a meetup
  • Tools for virtual conferences

Follow us

  • Facebook
  • Twitter
  • LinkedIn
  • Instagram
  • YouTube
  • RSS

DOWNLOAD APP

© Copyright Codemotion srl Via Marsala, 29/H, 00185 Roma P.IVA 12392791005 | Privacy policy | Terms and conditions

Follow us

  • Facebook
  • Twitter
  • LinkedIn
  • Instagram
  • RSS

DOWNLOAD APP

CONFERENCE CHECK-IN