{"id":43,"date":"2020-10-27T00:40:00","date_gmt":"2020-10-26T23:40:00","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/lessons-learned-from-load-testing\/"},"modified":"2022-01-05T20:06:14","modified_gmt":"2022-01-05T19:06:14","slug":"load-testing-lessons-learned","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/backend\/load-testing-lessons-learned\/","title":{"rendered":"Lessons Learned from Load Testing"},"content":{"rendered":"\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\tTable Of Contents\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
  1. What is Load Testing and how does it work?<\/a>
  2. Collect your metrics for load testing<\/a>
  3. If my system breaks, what can I do?<\/a>
  4. What are the outcomes?<\/a><\/ol>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\n\n\n

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

    In 2019, we had the pleasure to have Katie Koschland<\/strong> delivering an interesting talk about load testing<\/strong> during our conference in Rome. She talked about her experience<\/span> of finding a performance<\/span> problem on the Financial Times website. Although she and her team<\/span> 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.<\/p>\n\n\n\n

    What is Load Testing and how does it work?<\/h2>\n\n\n\n

    Load testing<\/span> is a type of performance test<\/span><\/strong> that measures how your system<\/span> behaves under a high load of users<\/span><\/strong>. What is important here is to collect metrics<\/span> 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<\/span> which usually runs in conjunction with a load test is stress testing<\/span><\/strong>, in which the aim is to break your system<\/span> using predictable or unpredictable scenarios<\/span>.<\/p>\n\n\n\n

    \"performance<\/figure><\/div>\n\n\n\n

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

    Today there are many frameworks<\/span> 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<\/span>, 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<\/a><\/span> Cloud<\/span> Load<\/span> Test<\/strong> to provide in no time a ready-to-use infrastructure.<\/p>\n\n\n\n

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

    npm install -g artillery<\/code><\/p>\n\n\n\n

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