jmeter-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 61000] New: HTTPS with HttpClient4 creates a separate SSL handshake for each request when Timer is used
Date Tue, 18 Apr 2017 03:30:58 GMT

            Bug ID: 61000
           Summary: HTTPS with HttpClient4 creates a separate SSL
                    handshake for each request when Timer is used
           Product: JMeter
           Version: 3.2
          Hardware: PC
            Status: NEW
          Severity: major
          Priority: P2
         Component: HTTP
  Target Milestone: ---

Created attachment 34920
Script to reproduce the issue

It appears that every SSL request is creating a new SSL handshake instead of
reusing the existing one when HttpClient4 implementation is used when a timer
is added. The behaviour is the same with JMeter 3.0, 3.1 and 3.2.

To test this I've created a JMeter script as follows:
- 1 Thread Group with the number of threads set to 2 and loop only once.
- Within the thread group two HTTP Request samplers were added and each has a
Constant Timer set to 3000 milliseconds. The HTTP Requests are GET requests to
an HTTPS URL of our application.
- HTTP Request Defaults is set to use the HttpClient4 implementation.

Each iteration in the thread group should create 2 requests and there are 2
users. So in total there would be 4 requests. However since the URL it is
hitting is the same, each user should be reusing the HTTPS connection of the
previous HTTP Request so only 1 SSL handshake should be created per user.

I've used Microsoft Network Monitor 3.4 to see how many SSL Handshakes are
being created and I have found that 4 SSL handshakes are made instead of 2.
Interestingly if I remove the Constant Timer the behaviour is that you have 2
SSL handshakes in total (1 per user) which is what I expect.

I'm using the default configuration with JMeter.
Is there any reason why the HTTPS connections are not reused?

You are receiving this mail because:
You are the assignee for the bug.
View raw message