Posts

JMeter Distributed Testing in Linux

Add the following to client (master) jmeter.properties (Preferably user.properties) file: remote_hosts= xxx.xxx.xxx.2,xxx.xxx.xxx.3 Add the following to servers (in each slave machines) jmeter-server : RMI_HOST_DEF=-Djava.rmi.server.hostname=xxx.xxx.xxx.2 for (Slave1) & RMI_HOST_DEF=-Djava.rmi.server.hostname=xxx.xxx.xxx.3 for (Slave2) Then start jmeter-server.sh from those two Slave machines( xxx.xxx.xxx.2 , xxx.xxx.xxx.3 ) using this command ./jmeter-server Then run the following command from the client machine(xxx.xxx.xxx.1) to start remote start all the slaves. ./jmeter -n -t <testscript.jmx> -r someuser@hostname-loadgen-002 bin]$ ./jmeter-server Created remote object: UnicastServerRef2 [liveRef: [endpoint:[10.170.14.8:44276](local),objID:[-4046dc45:16cae927316:-7fff, -2786700634234319895]]] Start test from Master machine with below command : ./jmeter -n -t  JMeter511_GooglePage.jmx -r Then we should see below output on slave machi

Distributed Testing in JMeter - Master Slave Configuration in Windows OS

Image
Distributed load testing in JMeter is the process of simulating large number of virtual users using multiples systems or load generators. One single machine may not be able to generate the desired virtual users for a load test due to its hardware capacity limitations and hence JMeter allow us to connect multiple machines to achieve the goal.  In JMeter, this is achieved by creating a Master-Slave configuration. For Example, You want to run a load test with 1000 virtual users but what if your machine is unable to generate more than 500 virtual users ? To overcome this issue, you can use the distributed testing in JMeter. Master:  T he system running Jmeter GUI, which controls the test. Slave:  the system running jmeter-server, which takes commands from the GUI and send requests to the target system(s). In other words, it’s the load generator machine which create the threads and send request to target system to simulate the user load. Target : the web server under test, g

Java Heap, Architecture and GC

The Java heap is the amount of memory allocated to applications running in the JVM.  Garbage collection (GC) refers to the automatic process of managing the run time memory.  The JVM is subject to GC pauses that vary in frequency and duration; if these pauses become more frequent and/or last longer, you will see issues (such as application pauses) which indicate that you may need to tune your Java heap.  The heap is initially created when the JVM starts and is split into different spaces or generations, the key ones being Young (Eden or Nursery) and Tenured (Old) Key symptoms that indicate you need to tune your Java heap are: High CPU usage. When GC threads consume a lot of CPU, you will see spikes in overall CPU usage. Application hangs. When your application appears to hang and stops responding, there are gaps in your log files or you experience general slowness when performing routine tasks, poorly tuned GC can be the cause.

Welcome to my Performance Testing and Engineering Blog

Tuning a Career in Performance: Performance Testing is a type of software testing to ensure software applications will perform well under their expected workload. A software application's performance like its response time, reliability, resource usage and scalability do matter. The goal of Performance Testing is not to find bugs but to eliminate performance bottlenecks. Performance Testing is popularly called “Perf Testing” and is a subset of performance engineering. Performance Testing is a discipline concerned with testing and reporting the current performance of a software application under various parameters. Performance engineering is the process by which software is tested and tuned with the intent of realizing the required performance. This process aims to optimize the most important application performance trait i.e. user experience. About me: Started career with AppLabs Technologies, (World's First Largest Independent Software Testing company) worked on all