Hi Felix, I also thought that at the begining and tried to apply some patches on code. Find them attached at : https://bz.apache.org/bugzilla/show_bug.cgi?id=58950
Note also I tried using 4.5.2 and uncommented this line in : - HTTPHC4Impl: ((AbstractHttpClient) httpClient).setReuseStrategy(DefaultClientConnectionReuseStrategy.INSTANCE); Regards On Sun, Jan 31, 2016 at 6:20 PM, Felix Schumacher < [email protected]> wrote: > Am 31.01.2016 um 18:07 schrieb Felix Schumacher: > >> Am 31.01.2016 um 17:52 schrieb Philippe Mouawad: >> >>> On Sun, Jan 31, 2016 at 5:45 PM, Felix Schumacher < >>> [email protected]> wrote: >>> >>> Am 31.01.2016 um 17:41 schrieb Philippe Mouawad: >>>> >>>> On Sun, Jan 31, 2016 at 5:30 PM, Felix Schumacher < >>>>> [email protected]> wrote: >>>>> >>>>> Am 30.01.2016 um 00:31 schrieb Philippe Mouawad: >>>>> >>>>>> Hello, >>>>>> >>>>>>> I made a real load test today using nightly build and faced an >>>>>>> important >>>>>>> issue. >>>>>>> >>>>>>> Here are the details: >>>>>>> - Test uses 1000 Threads on 1 Instance >>>>>>> - It uses "Download Embedded Resources" >>>>>>> - Socket Timeout is set to 10s >>>>>>> >>>>>>> No time between the requests? >>>>>>> >>>>>> Variable Time between requests. It is supposed to reproduce user >>>>> website >>>>> activity. >>>>> The timer is not fixed which can harden comparison but I always >>>>> reproduce >>>>> the difference of behaviour between version for all runs. >>>>> >>>>> So how many requests per second do you simulate (roughly)? >>>> >>>> 20 to 30 per second >>> >>> I tried to load test the ROOT webapp of tomcat 8 (without a timed delay) >>>> and did not get any Exceptions. >>>> >>>> Does it mean there is no network ? only locally ? >>>> >>> I am in ideal conditions in term of load testing as I am on a dedicated >>> machine. >>> >> OK. I think I see your problem (even if I don't see the exceptions). >> >> I test a locally running tomcat 8 with 1000 threads running for 1000 >> times one http sampler, which has a gaussian timer that was configured with >> 30000.0 and 300 milliseconds. >> >> Now, if I run it with httpclient4 I get errors after a short period of >> time (about 5 to 10 seconds). No errors, when run with httpclient3. >> > > If I let the test run with one round, only, there is no error. The same is > true, when I disable keep alive. So it seems to be a change in keep alive > handling. > > Regards, > Felix > >> >> >> Regards, >> Felix >> || >> >>> Regards, >>>> Felix >>>> >>>> >>>> >>>> Is your server capable of serving thousand requests simultaneously? >>>>> >>>>>> Yes, no problem on this side. >>>>>> >>>>> Number of requests per second is not high at all (50 samples included >>>>> Transaction Controller which encapsulate Http Requests ). >>>>> >>>>> >>>>> Regards, >>>>> >>>>>> Felix >>>>>> >>>>>> There is no overloading of the machine, no impacting GC >>>>>> >>>>>>> Very rapidly, I start getting a lot of errors: >>>>>>> >>>>>>> >>>>>>> - Non HTTP response code: >>>>>>> org.apache.http.conn.ConnectTimeoutException >>>>>>> message:Non HTTP response message: Connect towww.foo.com:80 >>>>>>> timed >>>>>>> out >>>>>>> >>>>>>> >>>>>>> Rate of error varies between 15% and 30%. >>>>>>> Note that if I navigate on the application, I don't face the errors. >>>>>>> >>>>>>> I ran the same test using exactly the same configuration: >>>>>>> >>>>>>> - Same machine >>>>>>> - Same JVM version and tuning >>>>>>> - Same user.properties >>>>>>> - Same hc.parameters >>>>>>> >>>>>>> But jmeter r1715087 >>>>>>> And error rate is 0.30%. >>>>>>> >>>>>>> >>>>>>> Note the target server has a load balancer that returns a keep-alive >>>>>>> duration set to 2 (2 seconds). >>>>>>> >>>>>>> This issue is a blocker one for the release of next version. >>>>>>> I compared code with revision 1715087 and I don't see many changes in >>>>>>> HTTPHC4Impl that would explain this regression. >>>>>>> I commented out some suspects , retried but I get same results. >>>>>>> >>>>>>> >>>>>>> I also upgraded to HttpClient 4.5.2 and uncommented the code >>>>>>> expected to >>>>>>> be >>>>>>> added, same results. >>>>>>> >>>>>>> So for now I tend to suspect an issue in HttpClient/Core. >>>>>>> >>>>>>> >>>>>>> >> > -- Cordialement. Philippe Mouawad.
