AutoMeter is an automation tool which helps us to create distributed load testing environment. It is developed and released by Intuit to open source world. It includes Jmeter in Docker image. It provides single command to start, stop test. At the end of the run, we get reports in master docker node. It can also be integrated with Jenkins easily for any of the CI requirements. What makes unique about AutoMeter is that it simplifies JMeter’s Master Slave configuration.Performance Testing in Jmeter Distributed environment can be triggered just by “One-Click”. To scale the load we can just add AutoMeter-Slave in autometer.config.js.

autometer --help  provides help manual

More details on installing an configuring AutoMeter can be found here https://github.com/intuit/autometer

Prerequisites

• One or more linux hosts with docker (>=1.12.5) installed.
• In one of the linux host install nodeJs (>=7) and autometer npm module. This node can be designated as master (from where tests has to be triggered).

Installation

npm install -g autometer

Comparison Between AutoMeter and BlazeMeter

We are living in the world of technologies, it changes the way we work, the way we look at the things. We search queries in google, do shopping online, share a moment in Facebook, chat with our childhood friends irrespective of where they live. Everyone likes if the tasks are simplified or automated by online solutions and gives more sophistication on our needs. Hence it is more important to design the web application by considering the performance factors such as concurrency, response time, fault tolerance, scalability. Though there are so many load testing tools available in the market, JMeter and Gatling are considered as widely used performance testing tools. Both JMeter and Galing are open source tools , Gatling also has enterprise version ‘Gatling Frontline’ “https://gatling.io/gatling-frontline/”

We had seen already about JMeter and how it helps QA to identify performance bottlenecks without worrying much on coding part as JMeter offers built-in components like Logical controllers, Samplers for protocols like http,ftp,Soap,Jms etc…, listeners for reports, Config elements like CSVDatasetConfig for customizing user data, Pre-Processors , Post-Processors such as Regex-Extractor, JMXMon for Monitoring the heap parameters of the Web application. Indeed JMeter is easy to use and it servers the purpose of finding the performance bottleneck, we have to agree on the fact that it has JMX format which makes script changes challenging.

Introduction on Gatling
Gatling is developed and maintained by Stephene Landelle. Gatling is well known for its speed and performance as it is built on AKKA Engine, Scala language based. Gatling works on asynchronous model. Gatling does not lock the thread at the jvm level, so there is no one user per thread concept. After thread completes it tasks , it will be released and takes the next task. Currently Gatling supports more on HTTP protocol , also they support JMS protocol.

As per https://gatling.io/performancetesting ,it has code-like scripting  which can help in continuous delivery pipeline. Gatling Domain Specific Language (DSL) helps easy-to-read for everyone.

Download Gatling from the following location, Latest version is Gatling 2.1.7
http://gatling.io/#/download

When you open Gatling you can see the following folders

bin
It has gatling recorder and gatling to run simulations for both windows and linux

conf
Gatling configuration files are placed here

lib
lib folder has Gatling Jar files , Scala libararies, netty libraries

results
results folder basically consists of simulation results, html files

target
where simulation class files can be found

user-files
user files are placed under data folder of this user-files directory.
simulation files are inside /user-files/simulation folder.

In many situations, we encounter in referring the variables from one thread group to another. Even I found myself every time I end up in searching for the solution. Finally, I have decided to write it here, there are many ways to transfer variables, I preferably choose the following method.

1) Set up Thread Groups
2) Add a “BeanShell Assertion” to the sampler where you are extracting the value
3) In the Script area of BeanShell Assertion specify as
${__setProperty(SG_Id2,${SG_Id1})} where SG_Id2 is a variable in which we are storing the value of
SG_Id1 , so that we can refer this value anywhere in the testplan across all the thread groups.
4) Now go to next Thread Group sampler where you want to pass the value and give as
${__property(SG_Id2)}
5) Now run the test and check the value passed from one thread group to another thread group

Scenario:

Do you have the following scenario to execute by Jmeter and not able to find the solution?

Having HTTP Request / REST Request in a test plan, required to execute the test for 1 hour duration without bothering repetition , and to

• Find the application robustness and consistency to bear max load?
• Find no. of requests application can handle for the specified duration?

and you would have

• tried giving in scheduler but not worked as it executes for the number of threads specified In thread group.
• tried giving in Duration but not worked. So what is next?

Solution:

• Check ‘Forever’ check box in Thread group
• Give Duration as ‘3600’ in Scheduler section of Thread Group

Enjoy Testing 

In this tutorial we are planning to explain step by step on how to record HTTP/HTTPS sessions.

Setup Instructions

1. Go to JMETER_HOME/bin and start JMETER with jmeterw.cmd and jmeter in linux/unix.
2. Select “Test Plan”, right click on “Test Plan” and add a new thread group: Add > Threads  (Users) > Thread Group.

3.  Select “Thread Group” right click, “Add –> Config Element –> HTTP Request Defaults”

4.  In new HTTP Request Defaults element: Server name – enter “host to be tested”, path can be left blank.

5. Right click on the “Thread Group” and add a recording controller: Add > Logic Controller >Recording Controller.

6.  Next, select WorkBench, Right click on WorkBench and add the recorder: Add -> Non-Test Elements -> HTTP(S) Test Script Recorder

7. On HTTP(S) Test Script Recorder, click the “Add” button in “URL Patterns to Include”. This will create a blank entry; enter “.*.html”. you can specify URL patterns to include and exclude such as *.html, *.js, which you would like to record.

8.  Right click on “HTTP(S) Test Script Recorder” and add a listener: Add -> Listener –> View Results Tree

9. Return to HTTP(S) Test Script Recorder, and click the “Start” button at the bottom.

This will start the JMeter proxy server which is used to intercept the browser requests. A file called ApacheJMeterTemporaryRootCA.crt will be generated in jmeter/bin folder. Install this certificate in your browser.

Note: If you browser already uses a proxy, then you need to configure JMeter to use that proxy before starting JMeter, using the command-line options -H and -P.

Configure Firefox To Use JMeter Proxy

We will use Firefox as our browser when using the JMeter HTTP(S) Test Script Recorder because, unlike Chrome and some other browsers, it does allows you to override system-wide configuration for its proxy settings.

Configure Firefox to use localhost (127.0.0.1) on port 8080 as its proxy for all traffic by following these steps:

1. Open Firefox
2. Go to the Preferences menu
3. Click on the Advanced tab
4. Then Network tab
5. In the “Connection” section, click on “Settings…”
6. Select the “Manual proxy configuration” radio button
7. Set HTTP Proxy to “localhost” and Port to “8080”
8. Check “Use this proxy server for all protocols”
9. Click OK and exit the Preferences menu

Note: When Firefox is configured to use JMeter’s Script Recorder as a proxy, it will only work properly if the Script Recorder is running.

Recording HTTP Requests

Now that our test plan’s HTTP(S) Test Script Recorder is running, and Firefox is configured to use it as a proxy, the HTTP requests that Firefox sends will be recorded. Let’s test it out.

In Firefox, go to your server’s homepage (the same server that you configured in your JMeter HTTP Request Defaults):

http://your_domain.com/

Now there should be a little triangle next to your Recording Controller. Click on it to expand and show the requests that it has recorded. You should see the HTTP requests that were recorded, depending on which URL Patterns you have included and excluded. Feel free to browse your site to record more requests.

As you can see, a lot of requests were created. You may refine the list of HTTP requests by simply deleting unwanted entries here.

If you do not see any entries under your Recording Controller, you will want to review your URL Patterns in the HTTP(S) Test Script Recorder (Hint: Remove all includes and excludes to record everything).

Once you are done recording, click the “Stop” button at the bottom of the HTTP(S) Test Script Recorder window. Note that Firefox will no longer be able to reach any pages (because it is configured to use port 8080 as a proxy)–configure it to use “No proxy” if you want to function normally.

Run Your Test Plan

Once you are happy with the test plan you have recorded, save it, then run it. It will function exactly like a manually created test, so you can configure it, delete, and add items to make it match your desired test case more closely.

Endurance Test:

Performing a long run load test and finding the performance bottleneck of the given server is called Endurance Test.

Often in performance testing  testers would face the following 2 scenarios,

1) Running single testplan for more than 8 hours

2) Running Multiple testplans one after another for more than 8 hours or overnight (without much of manual effort, just click run and go , take the report in the next day morning )

So what is the method of implementing the above 2 scenarios? Here is my suggestion though it depends entirely on your workload model requirement.

Scenario1:

To Run a single testplan ,

a) first calculate the hours that your test has to run in milliseconds

b) Add constant timer/uniform random timer to the samplers wherever it is required to pause the run and release it together.

c) Divide the time that you have in milliseconds from step #a , and put it in each timer.

d) Now Run the Test and make your life easy 🙂

 Scenario2:

Here it comes a simple feature and readily available in our Iron Man, JMETER.

a) Put all your thread groups under single test plan.

b) Right click on Testplan and check ‘Run Thread Groups consecutively’

 Happy testing 🙂 🙂 🙂

Sometimes it is necessary for the load test to send a linux command to verify the content/file exists in the remote linux server. Every time it is not a fair idea to connect remote server by file server browsers like winscp ,putty etc… as it is a load test. In such situations JMETER offers a sampler called ‘SSH sampler’ . This sampler is introduced to communicate with the linux server over ssh shell . It will be definitely useful for both Functional and Performance Testers.

Apache Jmeter’s SSH Sampler:

Sampler which will connect to linux server and execute linux commands

Steps in detail:

1) Download SSH Sampler plugin from google’s website
https://code.google.com/p/jmeter-ssh-sampler/
2) Copy the jar to your local Apache Jmeter’s “lib/ext” folder.

3) Download “jsch-0.1.51.jar” and place it in your local Apache Jmeter’s “lib/” folder.

4) Open Jmeter-> ThreadGroup->Samplers-> SSH Command

5) Give hostname,username, password and the linux command to be executed

6) Run Jmeter

7) Capture results in ‘View Results Tree’

Here is the image for your reference:

As per IBM notes

“IBM WebSphere MQ can transport any type of data as messages, enabling businesses to build flexible, reusable architectures such as service-oriented architecture (SOA) environments. It works with a broad range of computing platforms, applications, web services and communications protocols for security-rich message delivery. WebSphere MQ provides a communications layer for visibility and control of the flow of messages and data inside and outside your organization.”

WebSphere MQ provides:

• Versatile messaging integration from mainframe to mobile that provides a single, robust messaging backbone for dynamic heterogeneous environments.
• Message delivery with security-rich features that produce auditable results.
• High-performance message transport to deliver data with improved speed and reliability.
• Administrative features that simplify messaging management and reduce time spent using complex tools.
• Open standards development tools that support extensibility and business growth

More details can be availed from IBM website

For more information on Load testing IBM Websphere MQ using Jmeter check here.

These are Known performance issues in Oracle SOA Products and Oracle AIA Foundation Pack for 11g Release 1 (11.1.1.7):

• PermGen Space Out-of-Memory Error when Using the Sun JDK
• Maximum Heap Memory Size Recommendations on Windows 2008 Server
• Increasing the XA Transaction Timeout Value
• Inconsistent States for SOA Composite Application Instances in Recovery
• Google Chrome Browser Limitation on Displaying XML
• Exception: Internal Error While Activating AIAJMSSERVER (JMS Server)
• Dequeuer Returns the Same Message in High Concurrency Environments with Oracle Database 11.2
• Default/Last Active Revision of a Composite Is Not Identified When Retiring All Composites in a Partition.

For more information visit : http://www.oracle.com/technetwork/middleware/docs/aiasoarelnotesps6-1866030.html

 About :

For Loadtesting Apache Active MQ , JMS-Point-to-Point sampler in Jmeter will help us. Think that you do not have JNDI settings and no apache activemq for JMS messaging, instead IBM Websphere MQ is in place.  One day your manager is coming and asking you to test IBM MQ using open source testing tool as they do not ready to pay for small scale performance testing.

In that case , here is the steps to use Jmeter to load test IBM Websphere MQ.
The content here is pretty much precious and definitely it will save your valuable time 🙂

• Below are the Java and MQ jars needed.  Download these jar files and place it under Jmeter’s libext directory. ‘jmeter-jms-skip-jndi-0.0.1.jar‘ is the jar contains the MQ declaration and coding to connect it. You can down it from the URL : ‘http://www.java2s.com/Code/Jar/j/Downloadjmeterjmsskipjndi001jar.htm‘
  • com.ibm.mq.jar
  • org.springframework.beans.jar
  • org.springframework.jms.jar
  • javax.jms.jar
  • jmeter-jms-skip-jndi-0.0.1.jar
  • spring-core.jar
•  Open Jmeter -> File-> New->TestPlan -> Add Thread Group

• Under Thread Group add Samplers->JMS Point-to-Point Sampler and configure the parameter. As given in the below Screenshot.

•  Run Jmeter Script and Enjoy IBM MQ load testing .