Bug 63004 - Java vs. HTTPclient4 very slow response time difference, HTTPclient4 adding 30s to response time
Summary: Java vs. HTTPclient4 very slow response time difference, HTTPclient4 adding 3...
Status: NEEDINFO
Alias: None
Product: JMeter
Classification: Unclassified
Component: HTTP (show other bugs)
Version: 5.0
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-11 19:32 UTC by RuThaNiel van den Naar
Modified: 2020-02-26 20:12 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description RuThaNiel van den Naar 2018-12-11 19:32:34 UTC
Hello,
im using Jmeter for 12 years now, but there are everything new strange bugs.

 I met strange problem with new HTTP application, which im testing, in browser are response times from 2-20s for whole pages for all requests, this 1 problematic is 0-8s, in Jmeter for 1 request was response time almost always 30s+, in very few occasional iterations im getting fast response time 1-8s, but when i get slow its always over (like some wait is added or something like that) 30s, 30-38s. I run zillion of iterations, but i never got response between 8s and 29s!, always 30+, or <8s.

  I kept, investigating and when i used Java client+RedirectAutomatically option instead of HTTPclient4 is fine,i getting reasonable response times 0-8s. Any other any other combinations, failing, i tried httpclient4 with redirectAutomatically too, its the same, its still slow, +30s.. in 95% of cases. Its not some application hicup or something its reproducable, whole day long problem.

 I tried Jmeter 4/3.3 even Jmeter 3 with HTTP client3 and its accross multiple of version, there is some bug.

  Its simple scripts, no timers, no cycles etc.. just requests, transaction controller and lots of regular expression extractors and few results tree. Load is 1 to 5 users. Java 1.8 64 bit 1.8 191.

 Im using OpenVPN for scripting, antivir is turn down, but condion for all testing are the same.

  Application+data are not public, but i know that im doing, same scenario in SilkPerformer is fast too.
Comment 1 Philippe Mouawad 2018-12-11 20:25:15 UTC
(In reply to RuThaNiel van den Naar from comment #0)
> Hello,
> im using Jmeter for 12 years now, but there are everything new strange bugs.
> 
>  I met strange problem with new HTTP application, which im testing, in
> browser are response times from 2-20s for whole pages for all requests, this
> 1 problematic is 0-8s, in Jmeter for 1 request was response time almost
> always 30s+, in very few occasional iterations im getting fast response time
> 1-8s, but when i get slow its always over (like some wait is added or
> something like that) 30s, 30-38s. I run zillion of iterations, but i never
> got response between 8s and 29s!, always 30+, or <8s.
> 
>   I kept, investigating and when i used Java client+RedirectAutomatically
> option instead of HTTPclient4 is fine,i getting reasonable response times
> 0-8s. Any other any other combinations, failing, i tried httpclient4 with
> redirectAutomatically too, its the same, its still slow, +30s.. in 95% of
> cases. Its not some application hicup or something its reproducable, whole
> day long problem.
> 
>  I tried Jmeter 4/3.3 even Jmeter 3 with HTTP client3 and its accross
> multiple of version, there is some bug.
> 
>   Its simple scripts, no timers, no cycles etc.. just requests, transaction
> controller and lots of regular expression extractors and few results tree.
> Load is 1 to 5 users. Java 1.8 64 bit 1.8 191.
> 
>  Im using OpenVPN for scripting, antivir is turn down, but condion for all
> testing are the same.
> 
>   Application+data are not public, but i know that im doing, same scenario
> in SilkPerformer is fast too.

Hello,

1/ 
Can you attach a sample test plan ?
Or at least show your configuration:
- of HTTP Request 
- Thread Group
- HTTP Cookie Manager
- HTTP Header Manager

2/ Also please provide jmeter.log after activating debug mode:

in bin/log4j2.xml uncomment lines 75 / 76:
    <Logger name="org.apache.http" level="debug" />
    <Logger name="org.apache.jmeter.protocol.http" level="debug" />

Start jmeter and run the "buggy" request once .

3/ If you can also put fiddler capture.

4/ Also please provide some context on application


With current status 

Thank you
Comment 2 RuThaNiel van den Naar 2018-12-12 08:34:00 UTC
Thanks, for quite response.

1) Do you have some private email address for it? I cant share much just publicly on internet.

2) No problem, i will provide it.

3) I dont use Fiddler, i will not provide it in first round, but maybe later, if we will still in the darkness..

4) You will see this from test Plan, its just some Java Web application, during login processing is some redirecting - through Ajax-response CDATA.. in first call, to other that is use is url for second call it returns - 302 - a it follow redirect (this is slow).. When i use Redirect Automatically i see only - first and second call and second call shows - response of third call from first sequence.
  Im not quite sure, but it seems to that this behavior is occur too for some not working requests in same application and other request, often (not everytime) when i call something wrong.. bad request etc.. response take also very to appear (30s+).

 I can provide you privately some screen recording video if error + recording / replaying log (full XML - jtl files if you want).
Comment 3 Deepak Jha 2019-05-08 14:26:53 UTC
Thank god I finally saw atleast someone on the earth reported this.
At first I noticed issues with Ultimate Thread Group on Jmeter 3.3 where delay induced by Test Action was causing big variation in response times. It was fixed by upgrading Ultimate Thread group to latest version. 

Shortly later, I also noticed that HTTP sampler exhibits the behavior described in this bug which becomes worse with delay induced with test action or Timers. Switching to Java based client does resolve the issue for me (or so it seems).

Thanks for raising this bug. Is there any update on this though?
Comment 4 Philippe Mouawad 2019-05-08 14:30:32 UTC
(In reply to Deepak Jha from comment #4)
> Thank god I finally saw atleast someone on the earth reported this.
> At first I noticed issues with Ultimate Thread Group on Jmeter 3.3 where
> delay induced by Test Action was causing big variation in response times. It
> was fixed by upgrading Ultimate Thread group to latest version. 
> 
> Shortly later, I also noticed that HTTP sampler exhibits the behavior
> described in this bug which becomes worse with delay induced with test
> action or Timers. Switching to Java based client does resolve the issue for
> me (or so it seems).
> 
> Thanks for raising this bug. Is there any update on this though?

Hello,
Since you reproduce it, could you send a simple test plan which shows issue please ?
It should work against a public website ?
It not possible, then please provide what is requested in https://bz.apache.org/bugzilla/show_bug.cgi?id=63004#c1.

Thanks
Comment 5 RuThaNiel van den Naar 2019-05-08 18:13:52 UTC
Its true that i was using Ultimate Thread group from Jmeter plugins package and i dont see for long time, maybe because i switched to Stepping Thread group - which would be deprecated in some future releases.

  Problem of Ultimate thread group is that i can quickly set very small load for smoke test - i have to mess with ramp up etc.. with Stepping group its much quicker.
Comment 6 Philippe Mouawad 2019-05-08 18:20:00 UTC
(In reply to RuThaNiel van den Naar from comment #6)
> Its true that i was using Ultimate Thread group from Jmeter plugins package
> and i dont see for long time, maybe because i switched to Stepping Thread
> group - which would be deprecated in some future releases.
> 
>   Problem of Ultimate thread group is that i can quickly set very small load
> for smoke test - i have to mess with ramp up etc.. with Stepping group its
> much quicker.

Hello,
So you mean issue was related to UTG ?
It disappears when you switch to STG? 

Both of those components are managed at jmeter-plugins and are not part of core.

PS : I share your opinion on STG and you should react on this thread:
https://groups.google.com/forum/#!topic/jmeter-plugins/2ljKgHl2fo0

Thanks for clarification.
Comment 7 RuThaNiel van den Naar 2019-05-08 18:25:15 UTC
Even when its generated by adding plugin Thread group to project, there still could be problem on Jmeter side, that there are using some valid implementation which calling some bugged Jmeter code.

 So we still need to analyse that.