This is the second blog post referencing our recent “Performance Testing Considerations Using JMeter and Google Analytics” webinar. The first post focused on Google Analytics. We received quite a few questions we couldn’t answer in full during the webinar, so today we’re addressing the JMeter specific questions.
Q: Is there a better way to describe master/slave tasks? I find that language problematic. Main/secondary?
A: The terms “master” and “slave” were standard reference in engineering parlance when I first got started in the industry so it is habit to use it. Most of the industry has evolved to not using this terminology any longer, and we want to reflect this change, so everything below has been updated. Common replacement terms are leader/follower, parent/child, and master/replica. For our needs, we will be using master/replica below.
In the case of JMeter, the terminology in the webinar reflects that the master provides control over the replicas by informing the replica machines what scripts to run, as well as serving as a central source for the collection of resulting data.
replicas be VMs or needs to be physical machines?
A: Replicas do not need to be physical machines. They can be virtual machines. In this regard, JMeter can really take advantage of the ever-increasing availability, configuration, and location flexibility offered by cloud-based computing services like Amazon’s AWS and Microsoft’s Azure.
Q: Also, how to go about simulating replicas from different geo locations?
A: Configuring a master/replica configuration over geographic locations can be tricky. The key is that the master and replica machines must be configured utilizing public IP addresses. Also, the master will need to be configured to instruct the replicas on what tests to run, as well as what information to return to the master for post processing and analysis.
JMeter’s extensive plugin catalog is one of the reasons that XBOSoft has focused on JMeter as our performance tool of choice.
Q: With older versions of JMeter, when we schedule a load test with multiple load gen, we had to manually calculate ramp-up time to keep it uniform. Is that still the case? Also, reporting was pretty primitive before, what changes have been made?
A: With regard to ramp-up time, the Stepping Thread Group plugin (referenced in the webinar) is one that we often use to generate load of increasing intensity. That plugin, as well as others, are available at jmeter-plugins.org. There are also a host of plugins that provide a broad range of reports. JMeter’s extensive plugin catalog is one of the reasons that XBOSoft has focused on JMeter as our performance tool of choice.
Q: What would be the resources of every PC that will be JMeter injector and the amount of users per everyone in order to calculate the number of computers that we need to execute and the injectors work without blockers?
A: Metrics from the server under test can be monitored through various means. The “PerfMon” plugin on the JMeter master is a popular method. Additionally, a server agent needs to be installed within the testing environment. The agent can be installed as well on the application test server or the JMeter replicas. All statistics are be fed back to the JMeter master.
Some sites quote 300 as the maximum number of threads that can be run by any given JMeter instance. However, the amount of load that will be placed on the JMeter replicas will depend on the types of performance scripts being run, script complexity, RAM and CPU capacity, of the replica machines, etc.
You can use 300 as a rule of thumb to start, but our recommendation is to monitor the actual CPU and memory loads, as well as network throughout replica machines, during the times that the scripts are being executed, ensuring that there is headroom throughout the performance test execution.