Become a JMeter and Continuous Testing Pro

Start Learning

Test Your Website Performance NOW! |

arrowPlease enter a URL with http(s)

JMeter Releases 2.5 - A Whole New Fairy Tale


This is the first post in a series detailing all the new features JMeter has introduced in the latest releases; 2.5 and now 2.6.

And people, it's a whole new playing field.

In this article I will discuss one new JMeter feature that was introduced in V2.5+. It allows the settings of a concurrent connection pool for retrieving embedded resources as part of the HTTP sampler.

JMeter Cloud Testing Blog- Concurrent pool size
This is a very important feature that I’ve personally been waiting for with baited breath. Now that it has arrived, the way we build test scripts can change.


To explain the importance of this new feature - a sprinkling of background info.

How does a browser do it?

Once a browser fetches a page like an excited Golden Retriever chasing a ball, it subsequently fetches all of the page’s embedded resources (i.e. images, style sheets, script files, etc.). During fetch time, the browser can open a series of parallel connections to the remote server(s) hosting the embedded resources. Fetching the content of a page using parallel connections dramatically reduces the render time.

JMeter Cloud Testing Embedded Resources
Note above just how many embedded resources were fetched in parallel.


Prior to  V.2.5+, JMeter retrieved embedded resources of each page sequentially, not in parallel, thereby causing the page response time to be equal to the total of all embedded resources response times + the response time of the page (i.e. HTML) itself. Suffice to say that the response time reported by JMeter was much higher than the render time reported by the average browser.
Another downfall of the previous method (let’s call it ‘subsequent fetching’) was that the load implicated by JMeter was less realistic. Consider a load of 250 unique browser all creating parallel connections. This load is much higher than JMeter executing 250 sequential threads.
To summarize - Downfalls of JMeter prior to V2.5+:

  • The reported response time was much higher than the browser render time
  • The load of 250 users was not representing the load of 250 browsers.

These are obviously two major downfalls of JMeter when we want to create a realistic simulation. This is why the concurrent connections feature is so important.


The new concurrent connections feature allows JMeter to create a more realistic simulation. By allocating a pool of threads to retrieve the embedded resources, JMeter’s behavior more closely emulate the behavior of a browser.
With JMeter 2.5+ both of the two major downfalls described above are amended. The response time is now shortened and more inline with the render time of a browser. The load is more realistic and much higher.
The full report is accessible here:

JMeter Cloud Testing Aggregate Report

When comparing test results when running the same test with the connections pool enabled with 4 threads and when not enabled, it is obvious that the average response time without the connections pool was: 13,644 ms and with the connections pool enabled it was 5,557 ms.

JMeter Cloud Testing Single Thread & Thread pool Time

The reported response time without the connections pool enabled was more than doubled that as reported with multiple connections enabled.

JMeter Cloud Testing- Hits Report

The hit ratio without multiple connections was 2.25 hits per second while with the multiple connection it was 3.67 - over 60% more load with multiple connections enabled.
This new feature is obviously very important and I assume it will be now used in almost every test script. Anyone who is using this new feature should take in to consideration that this feature will have a major affect on JMeter and how it is used.

Generally, JMeter recommends that a test not go over the 300 thread limit for a single JMeter engine/console.

Until V2.5+, the number of threads was the number of threads in thread group. But now, the new concurrent connections pool should increase the overall number of threads per a test session.

For example- if we set the connections pool to 4 and the threads in the group to 300, we can get up to 1,200 threads per test session, while the recommendation is not to go over 300 threads. So, ideally, a user should consider reducing the number of threads in a thread group if they are using the connections pool. This way, the total threads in the test session will not be greater than 300. Otherwise the user risks overloading the engine/console itself.

Running a test with a concurrent connections pool uses more CPU resources that running without this pool enabled.

JMeter Cloud Testing CPU Usage Report 1


JMeter Cloud Testing CPU Usage Report 2

It’s obvious that activating the concurrent connections pool has an affect on resources consumed by JMeter.

The full report is accessible here:



The concurrent connections pool is a very important feature and represents a major leap in JMeter’s functionality. When activated, this feature upgrades JMeter’s simulation abilities to be more realistic. The response time is akin to the response time of a browser and the load capacity has increased. However, one should note that this feature does require additional resources from JMeter, or users run the risk of overloading your own testing resources.

Therefore, we strongly suggest using the concurrent connections pool BUT reducing the total number of threads so is will not be more than 300* threads per engine.


*Stronger engines can take on a higher load.



arrowPlease enter a URL with http(s)

You might also find these useful:

Interested in writing for our Blog?Send us a pitch!