Blazemeter and JMeter



ImpactQA recently did performance testing of Marathon website using Blazemeter. Here is how we carried out the testing.

 

Problem Statement


We wanted to stress test a .NET application and were not sure if we wanted to test using VSTS or JMeter. VSTS had its own advantages while JMeter could easily be configured in BlazeMeter. The .NET application was to be tested for a load of 10K users and the challenge was to test it remotely. The web server was hosted in the US and the tests were being conducted from a remote location in India.
To simulate a real time load environment we needed the client machine (load generating machine) in US (the servers were already hosted in the US). We needed 10 machines of 8 GB RAM and 3.0 GHz processor). Acquiring such machines in a short time frame in the US and that too only 2 weeks was not only an expensive affair but also time consuming and not worth the price.
That’s where BlazeMeter came in



Thanks to BlazeMeter we could simulate the load using the BlazeMeter as the client machine. The beauty of BlazeMeter is that it allows you to hit a server as if you are based out of that country – screenshot below.

There is also yet another user friendly feature of BlazeMeter that allowed user to set the parameters by dragging the slider. See below.



We selected 290 threads (number of concurrent users) to load test. The duration of Load Test was 1 hour.

We also want to share our experience of scripting a .NET application using JMeter where we were faced with a unique problem while scripting – the problem with ViewState. Although this had nothing to do with us using BlazeMeter we thought it would be a good idea to put it in this blog.


To know more about ViewState follow the link below..

 

The problem: If we do not correlate the ViewState variable the JMeter script may run 1st time but in subsequent run the script will create problems. The reason for this is that in the first run the application may accept your recorded ViewState value but when you run the script next time, it will fail as it will no longer accept the previous view state value.

 

Solution to the problem

Correlate the ViewState in the script if they exist in the application. Execute the following steps:



1.  Find the ViewState parameter



2.  Now see the HTTP Request Name (in our case its login)



3.   Search for the ViewState (Search in View Result tree) in the response of the login  that is just above the login in which you will find the ViewState parameter



4.   Extract it by using “Regular Expression Extractor” in the recorded “Login” sampler



5.  Now use the “Reference Name” (in our case it is ViewState_Login) as a variable name


Leave a Reply

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