• Skip to primary navigation
  • Skip to main content
  • Skip to footer

Chintu Gudiya Foundation

  • What We Do
    • Blog
  • Who We Fund
  • Projects
  • Grants
  • Financials
Project Tech4Dev

Load Test Using k6

You are here: Home / Blog / Load Test Using k6

twitter sharing button Share this on Facebook

Load Test Using k6


September 28, 2020 by Anshul Gupta
Leave a Comment

Moving forward with Glific development now we have started thinking about testing the application for handling high traffic, monitoring performance trends over time, and be alerted of performance regressions.

We decided to start using k6 for load testing. It is an open-source load testing tool to catch performance issues. It provides enough features to write smoke, load, stress, and soak tests. It also provides options for performance testing automation.

It is a well-documented tool, which gives an easy head start for load testing with enough material at initial steps answering why and how, 

  1. It suggests starting small with unit load tests and then move to more scenario-specific load tests.
  2. As load tests need time to ramp-up and execute the user journeys with the simulated traffic to gain enough measurements/data that can be acted on. Hence it is better to run it when merging code into a release branch or as a nightly build perhaps. 
  3. Load testing should happen pre-production.

To achieve maximum performance, the tool itself is written in Go, embedding a JavaScript runtime allowing for easy test scripting.

Now before going deep on features available, let’s look at the scripts code for reference

To understand complete code structure refer to the test life cycle. To get started scripts must contain, at the very least, a default function. Here we keep the check / assert for API responses. This defines the entry point for all VUs. 

And the results standard output looks like this: 

Let’s try to understand the features available here one by one.

  1. When using VUs concept it runs tests with more than one virtual user parallelly. We can also specify it while executing the k6 run command.
  1. k6 provides a list of built-in metrics that will be displayed in results standard output after completion of each test. Also, we can add custom metrics.

We can start with basic metrics like checks and http_req_duration to analyze our tests and to understand how the application is behaving with high load. We would need to use other metrics to analyze it in more detail and reach conclusions for performance improvements. A few of the metrics are:

  1. Vus, vus_max, iterations, iteration_duration, dropped_iterations, data_received, data_sent, checks
  2. HTTP-specific built-in metrics : Http_reqs, http_req_duration

Types of metrics are: gauge, counter, trend, rate.

  1. To visualize the result output over a period of time we can store it using JSON or InfluxDB output plugins (there are more options available). 

And then create the graphs as per our requirement. To visualize data stored in InfluxDB, Grafana open-source package is used, which provides charts, graphs, and alerts.

  1. More options can be added to the test scripts which include tags and groups, thresholds, stages (for ramping up/down the VUs).

Herewith specified thresholds the test will fail if “95% of API calls don’t return within 0.4s”. Using stages it will increase the number of virtual users gradually from 0 to 10 in the first 30s interval and then 10 to 20 in the next 30s interval. We can use all these available features according to our requirements.

Finally, for automated performance testing integrated with CI, we can refer to the guidelines here.

Category iconBlog Tag iconGlific

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Recommended reading

    Glific – What is GraphQL & Why we choose it for our project

    We as a team are into the second month of project Glific (also popularly known as Two Way Communications) & it has been very eventful. The initial month was all about learning, listening to NGOs & exploring different technologies to use for the project in the long run whereas now I would say we are

    June 24, 2020 by Anshul Gupta

Tags

#Tech4Good 66A analysis analytics architecture ASHWINI Avni conference Coronavirus COVID-19 crm-platform dataexplorer design research Discounts freespeech FundImpact github badges Glific Google governance hasiru dala ideation internetfreedomfoundation Jan Swasthya Sahyog Koha Koha Challenges Koha configuration Koha features Lastmilesupport library medha-stpc openchs opencity opendata open source Partnerships sesta Social Change Software Team Collaboration tech Tech4Dev Project Updates whatsapp Work from Home Yenepoya

Categories

  • Blog
  • Essays
    • 2015
    • 2016
    • 2017
    • 2018
  • Focus Areas
    • Organisations Funded
      • Education
      • Environment
      • Health
      • India
      • Open Source Software
      • Other
      • Philanthropy
      • Sanitation
      • Sports
      • Women Empowerment
    • Tech Work
  • Projects
  • Pune 2018 Unconference
  • Tech4Dev Project Report
  • Uncategorized

Footer

  • What We Do
    • Blog
  • Who We Fund
  • Projects
  • Grants
  • Financials

Copyright © 2021 Chintu Gudiya Foundation. All rights reserved. | Photo Credits