I'm I having a jmeter botleneck?

Question

First of all applogies if this has already been asked but I can't seem to find it anywhere.

Here's the scenario.

I have a 8 CPU Linux physical box with 8GB of memory on which I'm running a simple HTTP jmeter test against http://www.xpto.com/info.php which will give me a typical php info page.

If I run the test with 10 threads against one VM I get results of: - summary = 177665 in 158s = 1122.5/s Avg: 8 Min: 4 Max: 217 Err: 0 (0.00%)

Now, when I do the same test but with 40 threads agains 4 VMS the result does not extrapolate, so the result I get is something like: - summary = 535859 in 338s = 1584.6/s Avg: 24 Min: 2 Max: 155 Err: 0 (0.00%)

The 4 vms are on different Hypervisors so they don't impact each other. The VMS are SL6.4 with 8GB of mem and 8 CPUS.

Looking at the jmeter box I can see that I have plenty of free memory, there no out of memory errors, and the java process is using 80% of cpu. The load on the jmeter box is 0.5 with 92% cpu idle, or so.

The question is, do you think this could be a jmeter bottleneck? I've seen to have this sort of results with any tests I do against other URL's.

Thanks for the help.

--joao

Answer 1

It appears the current bottleneck occurs before you hit the server, possibly in JMeter client. It is not always easy to determine the cause, it may be a JVM limitation. You might be able to use jconsole or jvisualvm to get more clues. Also check bandwidth and other limits that may affect things before they reach the server.

Do the servers use a common DB? or common log? Make sure you have excluded everything else before you blame the client.

It is easy to test if JMeter is the bottleneck. Load the server from another client at the same time and see if it affects jmeter client results.

With a heavyweight client box, it might be better to run distributed slaves on localhost, so you have more JVMs, each with its own resources.

JMeter clients do not scale well, which is why distributed testing is useful. Clients don't really need to scale proportionally, as long as there is a means to keep increasing load on the server, and it is measurable.

Answer 2

I've recently seen something similar. The quick solution for me was to move to using Master-Slave JMeter execution and launch more JMeter slaves inside VMs. In my case I've been able to put 8 JMeter VMs on the same physical machine and scale my testing that way. Still investigating how I can get the same amount of load generation out of a single JMeter on bare metal.

Answer 3

No direct answer here, just some suggestions:

• run longer test, let say 20 to 30 minutes at minimum to have meaningful statistics
• always run a warm up run before the actual test
• tune properly the JVM: good starting point here http://www.ubik-ingenierie.com/blog/jmeter_performance_tuning_tips/
• 80% of CPU is rather high, it is not clear if this is the case with 1st or second test

ciao