How to install JMeter, what are the components of it and how to use it. It will, also, show a short introduction of what is performance testing.

First of all, let’s talk about Performance Testing. What is Performance Testing?

Performance Testing is a software testing process used for testing the speed, response time, stability, reliability, scalability and resource usage of a software application under a particular workload.  
The focus of Performance Testing is checking a software program’s

• Speed – Determines whether the application responds quickly
• Scalability – Determines the maximum user load the software application can handle.
• Stability – Determines if the application is stable under varying loads

What is the Purpose of doing it?

The main purpose of performance testing is to identify and eliminate the performance bottlenecks in the software application.

Now let’s introduce JMeter

How to install it?

JMeter is an application base in java. This means, that every computer with java installed can run this application. So let’s see how to install it.

1- Download Java.

 First of all, you will need to install Java on your computer. Here you can download and Install the latest version of Java SE Development Kit https://www.oracle.com/java/technologies/javase-downloads.html.

2- Download JMeter.

At the point of writing, the latest version is Apache JMeter 5.4.1 (Requires Java 8+) and you can download it here http://jmeter.apache.org/download_jmeter.cgi. Choose the Binaries file (either apache-jmeter-5.4.1.zip or apache-jmeter-5.4.1.tgz).

3- Installation.

Installing Jmeter is easy! You only need to unzip the file to a directory of your choice and that’s it!

4- Start JMeter

JMeter can be used in 3 modes. These 3 modes are:

1. GUI Mode
2. Server Mode
3. Command Line Mode

In this article, we will focus on GUI Mode. So, to start the GUI Mode, you will need to execute the following file /bin/ApacheJMeter.jar. This will open the application as the following example.

How to use JMeter?

Now that we have JMeter installed and running, we need to understand the components that are used to create a Test Plan.

When we open JMeter, we can see that there is already a “Test Plan” component. This component is where we add components for our JMeter Test. Here is an image of how these components are organized.

The components that we are gonna talk here will be:

• Thread Group
• Samplers
• Listeners
• Config Elements

Thread Group

Thread group is a collection of threads. This is the component where you define how many threads will run. Essentially, each thread represents a user using the application under test.

The thread group let’s you set the value of threads that you want to run(simulating the number of users, that you to test, using your app).For example, if you set threads number to 100. JMeter will create and make 100 request to the application under test.

Samplers

JMeter supports testing HTTP, FTP, JDBC and many other protocols.

We already know that Thread Groups simulate user request to the server, but how does a Thread Group know which type of requests (HTTP, FTP etc.) it needs to make? The answer is Samplers.

The user request could be FTP Request, HTTP Request, JDBC Request, etc. In this example, we will concentrate in HTTP Request.

Listeners

Listeners shows the results of the test execution. They can show results in a different format such as a tree, table, graph or log file.

Graph result listeners display the server response times on a Graph.

View Result Tree show results of the user request in basic HTML format.

Table Result show summary of a test result in table format.

Log show summary of a test result in the text file.

Config Elements

Set up defaults and variables for later use by samplers.

The figure below shows some commonly used configuration elements in JMeter.

Let’s create a test

As was shown before, JMeter starts with a Test Plan Component already created (you can change the name to anything more suitable to your case). 

Now let’s start creating our test. In this case we will use https://my-json-server.typicode.com/ to simulate an API.

Initially, let’s add a Thread Group. Right click on the test plan, then Add -> Threads(Users) -> Thread Group.

You can see that there is some settings that we need to adjust. At the top, there is a setting that says Action to be taken after a Sampler Error. Normally, I always use this in Continue but you can use the one that suits your case.

The next 3 settings will be the ones that we gonna focus for now.

• Number of Threads (users) – is the number of threads(users) that will be running your test plan.
• Ramp-up period (seconds) – is the value in seconds that defines how much time until all threads are working. Example: 100 Threads and 10 seconds of ramp-up period, this means that the threads will start, gradually, until at the point of 10 seconds all 100 threads will be working.
• Loop Count – You can set this to the Infinite and will only stop threads when you press the button to stop. Also, you can set a loop count, that is the times that each thread will execute the test plan. Example, if you put the value 3, the threads will execute the plan 3 times and then will stop.

So, in our example lets try 10 threads, with 5 seconds of Ramp-up Time and the value 3 in the loop count. I will also change the name of the thread group to know how many threads I am using. It Should look like this.

Let’s continue adding more components. This time, let’s add a way to define variables. Right-click on the Thread Group, then Add -> Config-Element -> User Defined Variables. 

This component will let you define some variable to use afterwards. Let’s define some.

• url: my-json-server.typicode.com
• postId: 1

 Now, to use these variables in other components you will need to do it in the following way.

• ${url} for the url Value 
• ${postId} for the postId Value

Finally, let’s add some real requests. Here as example we will make 3 different requests. Http Request to get all posts, Http Request to get one Post, and Http Request to Post a new Post. Remember that the site used in this example has paths to request posts and to add posts.

How to add an HTTP Request ? Right-click on the Thread Group, then Add -> Smapler -> Http Request.

Now that we have an Http Request component, let’s configure to make a Http Request to get all posts. The path to this request is https://jsonplaceholder.typicode.com/posts. The configurations of this component are:

• Protocol -> “https”
• Server Name or IP -> ${url} (because we have this value defined in a variable)
• Port Number -> in this case, nothing but if you need to your specific case, here is where you put the port number. Example: to make a request to https://localhost:80, you would need to put the value 80 in here.
• HTTP Request -> GET
• Path -> “/typicode/demo/posts”

Now that we have everything, let’s run ? Click on the start Button above and see what happens. Nothing ? Stop the process and let’s see what is missing.

The piece that is missing is listeners. We need listeners to understand what is happening. In this case, the View Results Tree and Summary Report. Let’s add these two listeners by Right-clicking in the Thread Group, then Add -> Listener -> View Results Tree and Add -> Listener -> Summary Report.

Now, if you start the process, you will see that these listeners represent information about the request. 

The View Results Tree show every request information. In here, you can see the request body and headers, and the response body and headers.

In this example, when we choose the Response Body of one request we will see that there will be a JSON with data relative to what they call as posts.

The Summary Report Aggregates the information of different types of request. In this case, we only have one request, so, it will show informations about that request.What are the informations that this will show ? 

• #Samples – are the number of requests made 
• Average – shows  the average time needed to make these requests 
• Min – shows the value of the request that take less time to finish
• Max – shows the value of the request that take more time to finish
• Std. Dev. – shows the standard deviation of the request times to the average
• Error % – shows the percentage of requests that failed
• Throughput – shows the number of requests processed by time 
• Received KB/sec –  shows the amount of data downloaded from the server  time
• Sent KB/sec – shows the amount of data uploaded to the server time 
• Avg. Bytes – shows the average size of the response sample

We have all we need, let’s add more Requests. Let’s create a request that creates a post, and create a request that obtains only one post. Also, change the name of the Http Request components to now what is the correspondent request. Remember to put the Http Request before the listeners. The Listeners will only listen to what are before them. Remember this! 

The create a post request configurations are:

1. Protocol -> “https”
2. Server Name or IP -> ${url} (because we have this value defined in a variable)
3. HTTP Request -> Post
4. Path -> “/typicode/demo/posts”
5. Body Data – we will put a JSON like this {“title”: “Car Crash”}

And, The get one post request configurations are:

1. Protocol -> “https”
2. Server Name or IP -> ${url} (because we have this value defined in a variable)
3. HTTP Request -> Get
4. Path -> “/typicode/demo/posts/${postId}”

Run the test plan and see the results. Try to do it for another API. 

These are the basic examples that we have for you right now. More advanced tips will come. 

See you next time.

References

• https://www.guru99.com/jmeter-element-reference.html
• https://www.guru99.com/hands-on-with-jmeter-gui.html

The post Performance Testing An API, How To Start Doing It With JMeter? appeared first on Blog IT.

For each possible implementation, we will do an overview of the flow that the exception does to understand the context of each implementation.

First, let’s do an overview of what is, normally, a basic flow in any Project.

The basic flow of an API Project

The previous Figure shows the basic flow of events inside the IDM project. The API receives an HTTP Request in a certain endpoint. The endpoints of the API are mapped in the controller layer, so when the API receives the HTTP request the controller is the first to interact with that request and sends that request to the respective service that will orchestrate all the necessities of that request. Those necessities could be, for example, retrieve some information from the Database, and that is done in the repository layer. The repository layer is where we map all the interactions with external services(DataBases, API, etc). This is a basic overview of what could be a basic API project.

The Exception Handling Problem

Taking into account the previous overview of the project, we want to make the process of handling exceptions the more clearest and efficient possible in terms of computational needs, but also in terms of code structure. To achieve this purpose we will describe three different ways of handling the exceptions.

Also, in this project, we have 2 different types of exceptions. They are:

• DomainException – This is the type of exception that is thrown when the error that happens is something that the API already expects;
• Exception – This could actually be any type of exception different from DomainException. This occurs when an unexpected error occurs in the API;

Reference to Middleware

In this case, we will use the ExceptionHandler middleware layer. The middleware layer is specific to .NET Core and we will not focus on that here. Take into account that we will use ExceptionHandler in the middleware pipeline to catch all the exceptions that are not treated.

Here is the reference to ASP.NET Core Middleware.

First Approach: Try-Catch on Controller Layer

This approach consists of catching and treating the DomainExceptions that are thrown by any of the layers (Controller, Service, or Repository) of the APIProject in the Controller layers. Take into account that all the unexpected exceptions are always treated in the ExceptionHandler of the Middleware.

Second Approach: Try-Catch in all Layers

This approach consists of all layers of the API Project being capable of catching exceptions and sending again the exception to the upper layers. The Controller layer is where the Domain Exceptions will be treated.

Take into account that in this case, the unexpected exceptions are caught by the layer that throws her and also by the rest of the upper layers. However, it is treated in the ExceptionHandler of the Middleware.

Third Approach: Encapsulate Exception in Response Object

This approach consists, as the name says, in encapsulating the exception in the Response Object. Instead of throwing the exception, we will send the Response object with a Failed message with an instance of the exception in the Response Object as a variable. This means that the system will not need to operate the throws of exceptions for the expected errors. They will be passed in the response object.

Take into account that only the unexpected exceptions are thrown to Middleware – ExceptionHandler to be treated.

Normal Response Object

public class OperationResult
{
        public OperationResult();

        public static OperationResult Success { get; }
        public bool Succeeded { get; protected set; }
        public IEnumerable<OperationError> Errors { get; }

        public static OperationResult Failed(params OperationError[] errors);
        public override string ToString();
}

New Response Object for this approach

public class OperationResult
{
        public OperationResult();
           
        public static OperationResult Success { get; }
        public bool Succeeded { get; protected set; }
        public IEnumerable<OperationError> Errors { get; }

        public static OperationResult Failed(params OperationError[] errors);
        public override string ToString();
        public Exception ExceptionHolder { get; set;} 
}

Fourth Approach: Catch all exceptions in Middleware – Exception Handler

The approach consists of throwing the exceptions whenever they happen and then let them be caught and treated by the middleware – ExceptionHandler. In this approach, we would create a different type of response for each type of exception for the ExceptionHandler send as Response.

This would centralize all the exception handling in one place.

Comparison of Exception Handling approaches

The post How to Handle known Exceptions? appeared first on Blog IT.