Rectangle 27 0

As you may see (or not) from the image the average time is 712ms when using jmeter with View Results in a Table. Notice that this listener doesn't print out the response body just the request stats.

And here is my code from Java :

public static void main(String[] args) throws Exception{        
        long totalTimeMS = 0;

        for (int i = 0; i < 10; i++) {

        long startTime = System.currentTimeMillis();


        HttpGet get = new HttpGet("http://stackoverflow.com");
        HttpClient client = new DefaultHttpClient();
        client.execute(get);       

        long endTime = System.currentTimeMillis();
        long duration = (endTime-startTime);
        totalTimeMS +=duration;
        System.out.format("Duration %d ms\n", duration);
        }

        System.out.format("Average time is %d ms", (totalTimeMS/10));
    }

So I do not care about the response body as well. But here are the results (lot faster) :

Duration 615 ms
Duration 263 ms
Duration 264 ms
Duration 262 ms
Duration 268 ms
Duration 266 ms
Duration 265 ms
Duration 266 ms
Duration 268 ms
Duration 263 ms
Average time is 300 ms

Now another case in jmeter when using View Results in a Tree when you can actually see the response body plus the View Results in a Table because we still need the time.

I'm not going to attach screenshot because the answer will become less readable but the average time this time is 812 ms so about 100ms more than previously.

Now the java code that cares about the response body (new method) :

public static String convertStreamToString(InputStream is) throws IOException {
        if (is != null) {
            StringBuilder sb = new StringBuilder();
            String line;
            try {
                BufferedReader reader = new BufferedReader(new InputStreamReader(is, "UTF-8"));
                while ((line = reader.readLine()) != null) {
                    sb.append(line).append("\n");
                }
            } finally {
                is.close();
            }
            return sb.toString();
        } else {
            return "";
        }
    }

And I've modified slightly the previous code so it prints out the response, simulating the jmeter behavior, posting relevant part :

HttpGet get = new HttpGet("http://stackoverflow.com");
        HttpClient client = new DefaultHttpClient();
        HttpResponse response = client.execute(get);       

        long endTime = System.currentTimeMillis();
        long duration = (endTime-startTime);
        totalTimeMS +=duration;
        System.out.println(convertStreamToString(response.getEntity().getContent()));
        System.out.format("Duration %d ms\n", duration);

Results are following :

Duration 678 ms  + (including printing of response body)
Duration 264 ms + (including printing of response body)
Duration 269 ms + (including printing of response body)
Duration 262 ms + (including printing of response body)
Duration 263 ms + (including printing of response body)
Duration 265 ms + (including printing of response body)
Duration 262 ms + (including printing of response body)
Duration 267 ms + (including printing of response body)
Duration 264 ms + (including printing of response body)
Duration 264 ms + (including printing of response body)
Average time is 305 ms

Reponse time went up by 5 ms. So I don't know how jmeter got to be faster than just plain java code. Anyhow jmeter is really great tool, one of the best one arround (for free).

Thanks for trying it out! If it's not too much trouble, could you try with a web server on your localhost. I think that's where the problem occurs.

With my code, I see no difference with sites hosted abroad. (I tested with s3.amazonaws.com). However, I see the difference with localhost and with servers on the same LAN.

So your conclusion is then it's not tool or code issue? it's a throughput/network/webservice issue?

I think it's a tool or code issue, since JMeter and the Java code have different results on sites that are near. It's important to me since I'm benchmarking sites on the same network. Thanks!

so you get the same results using my code? and which jmeter version? which httpclient version ?

java - Slow Apache httpclient 4.1 compared to JMeter - Stack Overflow

java jmeter apache-httpclient-4.x
Rectangle 27 0

HTTP Request - this has an implementation drop-down box, which selects the HTTP protocol implementation to be used: Java - uses the HTTP implementation provided by the JVM. This has some limitations in comparison with the HttpClient implementations - see below. HTTPClient3.1 - uses Apache Commons HttpClient 3.1. This is no longer being developed, and support for this may be dropped in a future JMeter release. HTTPClient4 - uses Apache HttpComponents HttpClient 4.x. Blank Value - does not set implementationon HTTP Samplers, so relies on HTTP Request Defaults if present or on jmeter.httpsampler property defined in jmeter.properties The Java HTTP implementation has some limitations: There is no control over how connections are re-used. When a connection is released by JMeter, it may or may not be re-used by the same thread. The API is best suited to single-threaded usage - various settings are defined via system properties, and therefore apply to all connections. There is a bug in the handling of HTTPS via a Proxy (the CONNECT is not handled correctly). See Java bugs 6226610 and 6208335. It does not support virtual hosts.

HTTPClient4

However if you need your requests to be as much like a real browser as possible you need to consider using following components:

  • In HTTP Request Defaults tell JMeter to retrieve all embedded resources and do in using thread pool of 2-5 requests (as real browsers do)
  • Use HTTP Cookie Manager - to simulate browser cookies and to deal with cookie-based authentication

Hi dmitri.. I am already using all the elements which you mentioned to act like a browser. My use case is to compare my site between http and https. But my real concern is that when i use HTTPclient 3.1, the response time is nearer to the response time of http. When i use HTTPclient 4, the response time is five time the response of http. As you mentioned, there will not be support for HTTPclient 3.1 in future. Why there is huge difference in response time between HTTPclient 3.1 and HTTPclient 4 ?

It looks like that you're experiencing the issue tracked as issues.apache.org/jira/browse/HTTPCLIENT-925. I've tested HttpClient 3 and 4 implementations locally against SSL-enabled Apache server and response times are nearly the same. I'd suggest to measure time from real browser and choose closest implementation. Personally I'd go for HttpClient 4 but you're fine to use HTTPClient 3.1 - no one is going to remove previous JMeter versions from download area and HTTPClient 3.1 is still present in the latest JMeter 2.11

Difference in response time between HTTPclient 3.1 and HTTP client 4 i...

https httpclient jmeter apache-httpclient-4.x