"Turn" jmeter short board and recommended solutions

With the application of JMeter, it is found that the limitation of jmeter is more and more and needs further expansion.

　　One, hundreds of trillion of sample log parsing appears outofmemory

The last few projects are the Java sample logs, which are all up to TPS, and the response time is in the hundred millisecond level, so during <60 minutes, the generated JMeter sample log reaches hundreds of megabytes.

With JMeter GUI parsing log, many times appear outofmemory, uncomfortable.

Evasive but not radical approach:

1) put the >4G memory on the Linux machine, set-xmx2048m or even higher boot jmeter.sh

2) put on 64-bit Java version

3) Reduce Java sample run time or number of times, reduce log size

4) for long-time scenarios, start with shell mode-Turn off jmeter-Rename the log generation to reduce the size of the journal

The fundamental method: Overwrite the JMeter log parsing section as none GUI, or parse the regular log in a more efficient language

　　Second, distributed multi-monitor machine

This is not the strength of jmeter. In particular, monitoring data on the NAS is required to monitor the number of iowait%,netstat connections.

Workaround:

Extend the DLL with LoadRunner monitor+.

　　Third, the test program is the client API

Because the JMeter run consumes a large amount of resources, it is not clear whether the client API itself has short-term objects or memory leaks.

After confirming that the client API itself has no concurrency problems, memory leaks, short-term object problems,

The client API can add some metric data output to Excel + combine JMeter to get more average, standard poor data

　　Four, target-oriented scene control

For example, require the control server resources under a certain load. If Linux machine load is required to be close to 5 o'clock, how much is the TPS solved?

As the system is affected by the application Cache,os Cache,nas CACHE, the use of jmeter alone will be very exhausting.

Workaround:

Using a Java multithreaded applet to initiate pressure + additional threads to retrieve the/proc directory data increases/decreases the number of pressure threads depending on the load. At the same time, the number of changing threads and the load of resources are exported to a file, which is analyzed for trending.

Re-use the number of threads to apply the feedback validation on the jmeter.

"Turn" jmeter short board and recommended solutions