Custom Sample or Protocol to complete the test

        In some scenarios, we will find that the various samples provided in Jmeter cannot meet our own needs, because the logic of stress testing in this world is always changing, so if we implement a set of testing logic at this time, this time Need to use the extensibility of jmeter. Let's take a look at how to develop such a custom Sample through a simple example? What is the lifecycle of a custom Sample?

package com.bijian.jmeter;

import org.apache.jmeter.config.Arguments;
import org.apache.jmeter.protocol.java.sampler.AbstractJavaSamplerClient;
import org.apache.jmeter.protocol.java.sampler.JavaSamplerContext;
import org.apache.jmeter.samplers.SampleResult;

public class LifecycleJMeterSample extends AbstractJavaSamplerClient {

    @Override
    public Arguments getDefaultParameters() {
        System.out.println("Get Parameter name! [getDefaultParameters]");
        return super.getDefaultParameters();
    }

    @Override
    public void setupTest(JavaSamplerContext context) {
        System.out.println("[setupTest]");
        super.setupTest(context);
    }

    @Override
    public void teardownTest(JavaSamplerContext context) {
        System.out.println("[teardownTest]");
        super.teardownTest(context);
    }

    @Override
    public SampleResult runTest(JavaSamplerContext ctx) {
        SampleResult result = new SampleResult();
        result.sampleStart();
        System.out.println("[runTest]");
        result.setSuccessful(true);
        result.sampleEnd();
        return result;
    }
}

        Among them, AbstractJavaSamplerClient is obtained from ApacheJmeter_Java.jar (in order not to report errors in the project, I simply and rudely copied all the jar packages under Jmeter-2.13\lib\ext to the project). The written class file is packaged with JMeter_Java.jar, put this Jar under lib/ext in the decompression directory of Jmeter, and restart jmeter.

        Add the thread group at a time, and the two components of the aggregation report, and add a new Sample (Java Sample) before the aggregation report component, as shown in the figure:

        Run the test and you can see the console output. After adjusting the control of the number of threads in the thread group several times, we will find that the teardowntest and setuptest methods in our custom class are executed for a thread in the thread group. The number of calls in the thread group actually refers to The number of times the runtest method was run.

        The configuration file of JMeter can be obtained by downloading the attachment "Java Request.zip".

 

Attachment: Jmeter's distributed testing (pros and cons)

        Here's how distributed testing is used, i.e. using one machine to control multiple machines to stress the target machine. Since the methods on Linux and Windows are somewhat different, here is how to configure it under Linux.

        First of all, we call the master control machine, the broiler that produces the stress is called JmeterServer, and the system to be tested is called Target.

        Step 1: Start JmeterServer. We can find the jmeter-server script in the Jmeter/bin directory and run it. Of course, if you need to adjust the performance parameters such as the memory of the server that generates the test load, we modify the memory parameters in this script jmeter.

        Step 2: Modify the jmeter.properties file in the jmeter/bin directory on the Master machine, and modify remote_hosts=localhost:1099,localhost:2010 to be the actual IP of your own JmeterServer. If there are more than one, you can separate them with commas.

        Step 3: Start master jmeter, when running the test script, choose: Run --> Remote Run --> Select IP or run all remotes. JmeterServer will run the running script set on the Master machine.

        Question: In actual use, I found that using the Jmeter in this mode to observe the actual test results in the Master, I found that the TPS is far lower than the TPS that can be achieved by using a traditional Jmeter to test. I feel that it may be due to the Jmeter. The RMI technology is used to transmit information in multi-machine cooperation. Maybe this technology itself has an impact on the performance of Jmeter, resulting in very slow pressure. This problem has not been fully certified, so if I directly use multiple machines to test and add up the TPS under the condition that the pressure generated by one machine test is not enough, it is rather silly, and I look forward to the heroes for guidance.

 

Article source: http://blog.csdn.net/chenleixing/article/details/43418185/