Performance Testing Tutorial Part 1: Getting Started

In this performance testing tutorial, I will discuss how to build a framework to test all your services and publish the results in a clear dashboard.

Getting started with Performance Testing

As a project grows, we build tons of services, interfaces, pages, and other features. After it reaches a certain size, though, we may start to have problems with the load times, users might start to complain about the site getting stuck in some areas, and we may start to lose users. When this happens, all of the people on the team start to run around trying to make all of the services work faster. However, in most cases, the site has already been hurt by the performance issues.

So, is there a way to start performance testing our environment to track all these issues before pushing everything to production? Can we start to develop a framework resilient enough to test all our services and environments before and after every code push?

There are tons of performance testing tools that are able to test the load and stress on sites, but we are going to start with JMeter, since it is a powerful, open-source application.

 

Performance Testing Using EventCloud

For this performance testing tutorial, we are also going to use EventCloud, a performance testing tool that you can use to test a few services. Basically, you just need to select the “become a tenant” option and start adding users in order to begin using it.

 

Running a simple performance test using JMeter

We are not going to cover all of the cool stuff that JMeter can do, since that would go beyond the scope of this post. For the purpose of this performance testing tutorial, I will just include the screenshots to show you what each test does.

The only thing that is different about using EventCloud is that we need to add a parameter to the header, for example:

 

Installing InfluxDB

InfluxDB is a Docker image that you can download from Docker Hub. You are going to need Docker installed to run InfluxDB; if you don’t have it, you can get it at the Docker official site.

Once you have Docker running, open a terminal to start writing commands. Depending on your installation, you may need to use “sudo” before entering the command “docker –version” just to make sure that you have Docker properly installed:

Now we need to install the InfluxDB image using the command “docker pull influxdb”:

Once the image is downloaded, we can run the command to create the image: “docker run -d -p 8086:8086 -v $PWD:/var/lib/influxdb influxdb”—remember to change the $PWD to a local folder.

If everything runs ok, we will be able to access the InfluxDB image. There are many ways to do it, but the easiest way is to access http://localhost:8086/query?q=show%20databases, which should display something like this:

InfluxDB uses database syntax, so you can run most of the commands after the “?q=” at the end of the URL. For this example, we are going to create a database for our EventCloud project like this: http://localhost:8086/query?q=create%20database%20eventcloud

And if we rerun the “show databases” command, it should display our new database at the end of the list.

 

Pushing data from JMeter to InfluxDB

There are several ways to push information to InfluxDB. The easiest way to do it is using the backend listener component that JMeter has, which will send some metrics to InfluxDB. There is another plugin developed by Novatec Consulting that sends the metrics that are required by the Grafana dashboard. To install it, you will need to download the “MeterInfluxDBBackendListenerClient.java” and paste it in the JMeter plugins folder. Once you have it, you will need to add the component to the JMeter test plan.

The backend listener will end up looking like that. The variables have the following meanings:

testName: The name that we use to define our test. Keep in mind that all the variables will be pushed to InfluxDB, so if you want to make changes to the rows, this is the way.

nodeName: The node name for the test. I prefer to use this variable as the testing environment (dev, QA, UAT, etc.).

influxDBHost: The IP for the host that has InfluxDB running. Currently, we have it on the same machine, so that’s why we are using localhost, but you can use another machine IP if necessary.

influxDBPort: By default, InfluxDB uses port 8086, but if for some reason you want to change it, this is the way to manage it.

influxDBUser: The username to access InfluxDB.

influxDBPassword: The password to access InfluxDB.

influxDBDatabase: The name of the database that we define in InfluxDB.

retentionPolicy: The time that we need to retain the data. By default, we can leave it on “autogen.”

samplerList: The list of samplers that will send information to InfluxDB.

useRegexForSamplerList: The variable that allows you to send certain samplers using regex.

The other way to do it is by using Line Protocol, which is the official way that the InfluxDB guys push data. For this performance testing tutorial, though, we will use the backend plugin for the sake of time. If you want to send custom metrics to InfluxDB, this is the way to do it. I recommend taking the time to read the documentation if you’re interested in learning more!  

 

Installing Grafana

Since we already have the Docker installed, we just need to download and install the Grafana image from the Grafana Docker Hub Page by using the command, “docker pull grafana/grafana”.

Then, we can create our container with the command “docker run -d -p 3000:3000 grafana/grafana”.

Now we can access Grafana at http://localhost:3000.

The default credentials are “admin/admin,” and you will be asked to change the password the first time you log in.

 

Adding InfluxDB to Grafana as a data source

To add a data source, we need to open the Grafana page. To do this, we can either go to the settings page and click on the “data sources” tab, or just select http://localhost:3000/datasources:

Click the “Add data source” button and select “InfluxDB.” Then, fill out the form like this:

Make sure that when you click the “Save and test” button, the green message is displayed.

 

Adding the dashboard to Grafana

Since Grafana dashboards are a little difficult to create from scratch, there are many ready-made dashboards that we can reuse and edit if necessary. You can check all of them out here. For this performance testing tutorial, we are going to use this one.

On the Grafana home page, go to “Import Dashboard.”

In the dashboard input field you can either put 1152 or paste the URL https://grafana.com/dashboards/1152. It will ask you to add a data source and a name, so make sure you select the one that we already created.

Then, just click the “import” button, and it will be up and running.

 

Adding a Jenkins job to schedule the tests to run periodically

We currently have a way to start getting metrics for our site, but it would be nice to have an automatic way to gather the metrics according to a specific schedule. For this application, we can use Jenkins, which will allow us to do just that.

Once we have Jenkins running we need to add an item, in addition to adding a bash or Windows command.

The command will be like this:

Jmeter -Jjmeter.save.saveservice.output_format=xml -n -t \PerformanceTests\EventCould.jmx -l EventCloud.jtl

The command options are:

-n: this will tell JMeter to run in a non-GUI mode

-t: this is the test directory

-l: this is the log directory

Once we have the command ready, the only thing missing is the schedule trigger. This is an Ant command, so you can check out the documentation if you’re not familiar with this type of commands. This is an example of a job that runs every weekday at 3:00 p.m. and 8:00 p.m.

And there you go: this performance testing tutorial has shown you how to create a complete framework to manage and monitor your web services! Grafana will present the metrics on a readable, non-technical dashboard that your clients can benefit from. From now on, you just need to add all the new services and compare the metrics every time the developers make a significant change to those services, ensuring that the service doesn’t lose performance. Stay tuned for part two of this performance testing tutorial.