Testing MongoDB on Kubernetes with locust — First impressions — Part 2

Image for post
Image for post

This article gives my first impressions on trying out load testing Mongodb on Kubernetes with Locust load testing framework.

The first part deals with the Mongo application and connecting to it from my laptop for running the tests.

From https://docs.locust.io/en/stable/what-is-locust.html

Locust is an easy to use, scriptable and scalable performance testing tool.

You define the behaviour of your users in regular Python code, instead of using a clunky UI or domain specific language.

This makes Locust infinitely expandable and very developer friendly.

Even though the reason for going with locust was ease of installation, i instantly fell in love with clean, minimalist UI and very low entry barrier.

Prerequisites: Python 3.6+ , pip3

Installation https://docs.locust.io/en/stable/installation.html was pretty simple:

$ pip3 install locust

I’m ready to write locust tests now. I searched for a super quick video on youtube on writing a simple locust file. One video i liked is https://www.youtube.com/watch?v=L5Tjh19540I

so i ended writing a super simple python file as below:

PS: The above require pymongo package to be installed.

Writing locust tests is pretty simple. You just need to extend User class and annotate the function which does your work with @task annotation.

From https://docs.locust.io/en/stable/writing-a-locustfile.html#user-class

A user class represents one user (or a swarming locust if you will). Locust will spawn one instance of the User class for each user that is being simulated.

If you want to write a http load testing, you can extend Httpuser which has inbuilt support for making http requests. If you want to write tests for any task like say load testing a database, you can extend User class.

From https://docs.locust.io/en/stable/writing-a-locustfile.html#tasks

When a load test is started, an instance of a User class will be created for each simulated user and they will start running within their own green thread. When these users run they pick tasks that they execute, sleep for awhile, and then pick a new task and so on.

So in short there are just 4 steps to be done for writing your locust tests:

  1. Extend the user class.
  2. Write a function which does your work and add a @task annotation. Add a wait_time variable which defines how much time the tasks should sleep. This is mandatory and you can set any time you want.
  3. You can set if a request is success or failure by firing an event using environment.events.request_success.fire or environment.events.request_failure.fire method. This will help locust record the request success/failure data.
  4. Run the locust framework using locust -f FILE_NAME.PY . This will open up a UI which can be used to set users and rate of swarming users.
Image for post
Image for post

If you don’t want to provide a UI, you can provide it on cli too.

$ locust --users 10000 --spawn-rate 100

You can read more about the in-built classes at https://docs.locust.io/en/stable/api.html#api

Observations: The requests per second (RPS) was not so great, it reached ~200 for me. Probably because of limited cpu cores on my laptop. I guess it’s better if we can run distributed locust for more efficient load testing https://docs.locust.io/en/stable/running-locust-distributed.html

Happy load testing :P

Written by

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store