You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jakarta.apache.org by sebb <se...@gmail.com> on 2011/08/23 15:51:44 UTC

Re: Lots of CLOSE_WAIT with HC4 HTTP implementation

On 23 August 2011 14:23, Milamber <mi...@apache.org> wrote:
> Hello,
>
> I thinks I found a issue with HttpClient 4.1 on JMeter 2.5.
>
> I've a (big) JMeter test (+800 http requests) on 3 Thread Groups.
> TG1 => 63 users
> TG2 => 38 users
> TG3 => 14 users
>
> Scheduler test with a duration: 1800 secs (ramp-up : 200 secs, and sync
> timer 0.33 sampler/min)
>
> Platform is a server with Linux 64 bits (debian 6), JDK is 1.7.0 (same
> issue with 1.6u27)
> (ulimit -n 60000)
>
> With a HTTP Requests Defaults with HC4 implementation (used by all
> requests), after ~650 secs, I've this stats:
>
> netstat -tuplan > Netstat-hc4
>
> grep java Netstat-hc4 |wc -l
> 32676
>
> grep java Netstat-hc4 |grep ESTA | wc -l
> 319
>
> grep java Netstat-hc4 |grep TIME_WAIT | wc -l
> 0
> grep java Netstat-hc4 |grep CLOSE_WAIT | wc -l
> 32356 ===> too big!
>
> After some time, JMeter shows this errors (and test failed):
> java.net.BindException: Adresse deja utilisee (Address already used)
>    at java.net.PlainSocketImpl.socketBind(Native Method)
>    at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:374)
>    at java.net.Socket.bind(Socket.java:627)
>    at
> org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:116)
>    at
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
>    at
> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
>    at
> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
>    at
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:573)
>    at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
>    at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
>    at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:262)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:999)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:985)
>    at
> org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:381)
>    at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:274)
>    at java.lang.Thread.run(Thread.java:722)
>
>
> With the same JMeter (same platform), but with a HC3.1 implementation on
> HTTP Requests Defaults, the test is successful (no error)
>
> After ~650 secs, I've this stats:
>
> netstat -tuplan > Netstat-hc31
>
> grep java Netstat-hc31 |wc -l
> 628
>
> grep java Netstat-hc31 |grep ESTA | wc -l
> 108
>
> grep java Netstat-hc31 |grep TIME_WAIT | wc -l
> 0
>
> grep java Netstat-hc31 |grep CLOSE_WAIT | wc -l
> 519 ==> good
>
> I believe is a HTTPClient issue, on close connection?
> (http://www.sunmanagers.org/pipermail/summaries/2006-January/007068.html)

I think it's more likely to be that JMeter is not tidying up the HC4
connections properly.

Are you using Keep-Alive?

Can you reproduce the problem with a simpler test case, e.g. one that
could be run against a local server.

>
> Milamber
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org


Re: Lots of CLOSE_WAIT with HC4 HTTP implementation

Posted by Stéphane Hoblingre <st...@gmail.com>.
Also response time reported by JMeter is much higher with hc4 than hc3, see
attached charts...

Stephane

2011/8/23 Stéphane Hoblingre <st...@gmail.com>

> Hi,
>
> I can confirm the issue on Win7 64bit jdk 1.6.0_24 also... On the posted
> scenario, after 30 sec of execution HC4 is down, you can see it in attached
> charts...
>
> Stephane
>
>
> On Tue, Aug 23, 2011 at 9:57 PM, Milamber <mi...@apache.org> wrote:
>
>>
>>
>> Le 23/08/2011 16:13, Milamber a ecrit :
>> >> Can you reproduce the problem with a simpler test case, e.g. one that
>> >> > could be run against a local server.
>> >> >
>> >>
>> > Yes on my laptop (Debian 6 / 64 bits / openjdk 1.6u18)
>> >
>>
>> Same issue with a Windows XP 32bits / SunJDK 1.6
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>

Re: Lots of CLOSE_WAIT with HC4 HTTP implementation

Posted by Stéphane Hoblingre <st...@gmail.com>.
Hi,

I can confirm the issue on Win7 64bit jdk 1.6.0_24 also... On the posted
scenario, after 30 sec of execution HC4 is down, you can see it in attached
charts...

Stephane

On Tue, Aug 23, 2011 at 9:57 PM, Milamber <mi...@apache.org> wrote:

>
>
> Le 23/08/2011 16:13, Milamber a ecrit :
> >> Can you reproduce the problem with a simpler test case, e.g. one that
> >> > could be run against a local server.
> >> >
> >>
> > Yes on my laptop (Debian 6 / 64 bits / openjdk 1.6u18)
> >
>
> Same issue with a Windows XP 32bits / SunJDK 1.6
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>

Re: Lots of CLOSE_WAIT with HC4 HTTP implementation

Posted by Milamber <mi...@apache.org>.

Le 23/08/2011 16:13, Milamber a ecrit :
>> Can you reproduce the problem with a simpler test case, e.g. one that
>> > could be run against a local server.
>> >   
>>     
> Yes on my laptop (Debian 6 / 64 bits / openjdk 1.6u18)
>   

Same issue with a Windows XP 32bits / SunJDK 1.6



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org


Re: Lots of CLOSE_WAIT with HC4 HTTP implementation

Posted by Philippe Mouawad <ph...@gmail.com>.
Hello Milamber,
Is there a Jmx test file and a public facing site we CAN use to reproduce
issue ?


Thanks
Regards
Philippe

On Wednesday, September 21, 2011, Milamber <mi...@apache.org> wrote:
> Hello,
>
> Sorry, but the problem don't seems resolve.
>
> Today, I try a load test on a Content Delivery Network (CDN) with HC3.1
> vs HC4 with last JMeter trunk (r1173449).
>
> My script :
> Test only static resources (gif, png, jpeg) with direct HTTP Request
> 100 users
> Ramp up : 100 secs
> Duration test : 300 secs (5min)
> Each iteration execute 39 HTTP requests
> HTTP requests : Keep Alive true
>
>
> I have 2 issues (on 8 same tests: 4 HC3.1 and 4 HC4.1) :
>
> *_Issue 1_*
> With HC 3.1 : always no error
> With HC 4.1 : always some errors at the beginning of load test
>
> Stack trace (on view result tree: response data) is :
> org.apache.http.NoHttpResponseException: The target server failed to
respond
>    at
>
org.apache.http.impl.conn.DefaultResponseParser.parseHead(DefaultResponseParser.java:101)
>    at
>
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:252)
>    at
>
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:281)
>    at
>
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:247)
>    at
>
org.apache.http.impl.conn.AbstractClientConnAdapter.receiveResponseHeader(AbstractClientConnAdapter.java:219)
>    at
>
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:298)
>    at
>
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
>    at
>
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:645)
>    at
>
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:464)
>    at
>
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
>    at
>
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
>    at
>
org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:265)
>    at
>
org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
>    at
>
org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1010)
>    at
>
org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:996)
>    at
>
org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:383)
>    at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:276)
>    at java.lang.Thread.run(Thread.java:722)
>
>
> HC 4 Summariser (begin) :
> summary +    55 in   2,2s =   24,9/s Avg:    71 Min:    15 Max:  1677
> Err:     0 (0,00%)
> summary +  5027 in  30,0s =  167,5/s Avg:   103 Min:     1 Max:  1816
> Err:    14 (0,28%)
> summary =  5082 in  32,2s =  157,8/s Avg:   103 Min:     1 Max:  1816
> Err:    14 (0,28%)
> summary +  5013 in  31,4s =  159,7/s Avg:   283 Min:     2 Max:  3500
> Err:    11 (0,22%)
> summary = 10095 in  62,2s =  162,3/s Avg:   192 Min:     1 Max:  3500
> Err:    25 (0,25%)
> summary +  5075 in  31,6s =  160,7/s Avg:   449 Min:    37 Max:  7999
> Err:     0 (0,00%)
> summary = 15170 in  92,2s =  164,5/s Avg:   278 Min:     1 Max:  7999
> Err:    25 (0,16%)
> summary +  4984 in  34,8s =  143,2/s Avg:   587 Min:    40 Max: 11028
> Err:     0 (0,00%)
> summary = 20154 in 122,2s =  164,9/s Avg:   355 Min:     1 Max: 11028
> Err:    25 (0,12%)
> */_
> Issue 2 :_/*
>
> With HC3.1 after ramp up:
>  netstat -tplna|grep java|grep ESTA|wc -l
> 100
>
> With HC4.1 at beginning and after ramp up :
> netstat -tplna| grep java | grep ESTA | wc -l
> 1145 (value change between ~1000-1150)
>
> I make a tcp dump and analyze with wireshark.
> With HC3.1 : 0-42 secs : 43 TCP conversations (inside several HTTP GET
> and response)
> With HC4.1 : 0-44 secs : 3011 TCP conversations (inside one HTTP GET and
> one response)
>
> HTTP conversations show Keep-Alive header (HC3 and HC4)
>
> I suppose that is a close keep alive connection problem with JMeter.
> Perhaps 2 issues are linked?
>
> Milamber
>
>
> Le 24/08/2011 11:40, sebb a ecrit :
>> On 24 August 2011 02:43, sebb <se...@gmail.com> wrote:
>>
>>> Looks like HTTPHC4Impl is not reusing HttpClient instances.
>>>
>>> It should only create one per thread per unique URL + some other fields.
>>>
>>> It seems not to be finding the previously created instances, so it
>>> creates a new one for every sample.
>>> Not sure why yet; probably something simple.
>>>
>> Very simple.
>>
>> The equals() method was returning false if the other object was the
>> correct type, instead of returning false for the incorrect type.
>> So the hash keys never matched.
>>
>> Nightly builds from r1160957 will have the fix.
>>
>>
>>> However the code does at least seem to be closing the connections at
>>> end of thread.
>>>
>>> On 23 August 2011 17:13, Milamber <mi...@apache.org> wrote:
>>>
>>>> [snip]
>>>>
>>>>>> I believe is a HTTPClient issue, on close connection?
>>>>>> (
http://www.sunmanagers.org/pipermail/summaries/2006-January/007068.html)
>>>>>>
>>>>>>
>>>>> I think it's more likely to be that JMeter is not tidying up the HC4
>>>>> connections properly.
>>>>>
>>>>> Are you using Keep-Alive?
>>>>>
>>>>>
>>>> Yes.
>>>>
>>>>
>>>>> Can you reproduce the problem with a simpler test case, e.g. one that
>>>>> could be run against a local server.
>>>>>
>>>>>
>>>> Yes on my laptop (Debian 6 / 64 bits / openjdk 1.6u18)
>>>>
>>>> in attachment JMeter testcase.
>>>>
>>>> With HC4 impl:
>>>> summary =  2590 in  72.4s =   35.8/s Avg:   994 Min:   487 Max:  4806
>>>> Err:     0 (0.00%)
>>>>
>>>> Stats at ~ 72secs :
>>>> netstat -tuplna|grep java |wc -l;
>>>> 1494
>>>> netstat -tuplna|grep java|grep ESTA|wc -l;
>>>> 167
>>>> netstat -tplnau|grep java|grep CLOSE_WAIT|wc -l;
>>>> 1337
>>>>
>>>>
>>>> With HC3 impl:
>>>> summary =  4498 in  83.2s =   54.1/s Avg:   448 Min:   246 Max:  2489
>>>> Err:     0 (0.00%)
>>>>
>>>> Stats at ~83 secs:
>>>> netstat -tuplna|grep java |wc -l;
>>>> 61
>>>> netstat -tuplna|grep java|grep ESTA|wc -l;
>>>> 60
>>>> netstat -tplnau|grep java|grep CLOSE_WAIT|wc -l;
>>>> 0
>>>>
>>>> NB: more requests in same time with HC3.
>>>> NB2: HC3 ESTABLISHED connections is lesser than HC4 (60 users in JMeter
>>>> scripts)
>>>>
>>>>
>>>> Milamber
>>>>
>>>>
>>>
>>
>
>

-- 
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie

Re: Lots of CLOSE_WAIT with HC4 HTTP implementation

Posted by sebb <se...@gmail.com>.
On 22 September 2011 09:18, Milamber <mi...@apache.org> wrote:
>
>
> Le 21/09/2011 23:49, sebb a ecrit :
>> On 22 September 2011 00:13, Milamber <mi...@apache.org> wrote:
>>
>>> [snip]
>>> netstat -tplna| grep java | grep ESTA | wc -l
>>> 39 (esta conn)
>>>
>>> ==> 39 is the number of http requests in my test plan
>>>
>> I see the problem now.
>>
>> The httpclient cache key includes the full URL, so only reuses
>> connections for identical URLs.
>>
>> It should match on host name, port and protocol.
>>
>> If you test instead with identical URLs - or loop a single URL - it
>> should work the same as HC3.1
>> That's why I did not spot it earlier.
>>
>> I'll work on a fix now.
>>
>
>
> Your last commit fixes the problem.
> Now 1 connection with second test case (bug 51863), and 100 connections
> with my load test with 0% error during the test (second issue fixed too).
>
> Thanks.

I'm glad you spotted the issue.

>>>> [I think we need to fix this before releasing 2.5.1
>>>
>>> Yes sure.
>>>
>>>
>
> Any objection now to start RC1 process tonight?
>

No objections, go ahead.

I don't think there are any other issues that cannot wait.

It's sometimes tempting to add just one more fix, but then the process
can slip and slip ...


> Milamber
>
>
>
>>>
>>>>
>>>>> HTTP conversations show Keep-Alive header (HC3 and HC4)
>>>>>
>>>>> I suppose that is a close keep alive connection problem with JMeter.
>>>>> Perhaps 2 issues are linked?
>>>>>
>>>>>
>>>> Dunno yet.
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org


Re: Lots of CLOSE_WAIT with HC4 HTTP implementation

Posted by Milamber <mi...@apache.org>.

Le 21/09/2011 23:49, sebb a ecrit :
> On 22 September 2011 00:13, Milamber <mi...@apache.org> wrote:
>   
>> [snip]
>> netstat -tplna| grep java | grep ESTA | wc -l
>> 39 (esta conn)
>>
>> ==> 39 is the number of http requests in my test plan
>>     
> I see the problem now.
>
> The httpclient cache key includes the full URL, so only reuses
> connections for identical URLs.
>
> It should match on host name, port and protocol.
>
> If you test instead with identical URLs - or loop a single URL - it
> should work the same as HC3.1
> That's why I did not spot it earlier.
>
> I'll work on a fix now.
>   


Your last commit fixes the problem.
Now 1 connection with second test case (bug 51863), and 100 connections
with my load test with 0% error during the test (second issue fixed too).

Thanks.

>>> [I think we need to fix this before releasing 2.5.1
>>
>> Yes sure.
>>
>>     

Any objection now to start RC1 process tonight?


Milamber



>>     
>>>       
>>>> HTTP conversations show Keep-Alive header (HC3 and HC4)
>>>>
>>>> I suppose that is a close keep alive connection problem with JMeter.
>>>> Perhaps 2 issues are linked?
>>>>
>>>>         
>>> Dunno yet.
>>>
>>>
>>>       
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>>     
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org


Re: Lots of CLOSE_WAIT with HC4 HTTP implementation

Posted by sebb <se...@gmail.com>.
On 22 September 2011 00:13, Milamber <mi...@apache.org> wrote:
>
>
> Le 21/09/2011 22:42, sebb a ecrit :
>> On 21 September 2011 22:29, Milamber <mi...@apache.org> wrote:
>>
>>> [snip]
>>>
>>> I make a tcp dump and analyze with wireshark.
>>> With HC3.1 : 0-42 secs : 43 TCP conversations (inside several HTTP GET
>>> and response)
>>> With HC4.1 : 0-44 secs : 3011 TCP conversations (inside one HTTP GET and
>>> one response)
>>>
>> Do you mean that each HC4.1 conversation only contains a single
>> request/response?
>>
>
> Yes a single request/response
>
>> Can you enable debug logging for HTTPHC4Impl ?
>>
>
> Yes I can, I will sent the log in a private mail
> see end of log : one user but lot of:
> 2011/09/22 01:06:56 DEBUG - jmeter.protocol.http.sampler.HTTPHC4Impl:
> Thread Finished
> 2011/09/22 01:06:56 DEBUG - jmeter.protocol.http.sampler.HTTPHC4Impl:
> Thread Finished
>
>
>> This should show if the clients are being reused or not.
>>
>> I suggest you reduce thread and loop counts, or the log file will be very big.
>>
>
> Done: 1 thread, 1 sec ramp up, 30 secs duration
>
> Starting the test @ Thu Sep 22 01:06:25 CEST 2011 (1316646385910)
> Waiting for possible shutdown message on port 4445
> summary +   188 in   3,7s =   50,9/s Avg:    18 Min:     8 Max:   113
> Err:     0 (0,00%)
> summary +  1697 in  26,1s =   65,1/s Avg:    14 Min:     8 Max:   173
> Err:     0 (0,00%)
> summary =  1885 in  29,8s =   63,3/s Avg:    15 Min:     8 Max:   173
> Err:     0 (0,00%)
> Tidying up ...    @ Thu Sep 22 01:06:56 CEST 2011 (1316646416091)
> ... end of run
>
>
>
> netstat -tplna| grep java | grep ESTA | wc -l
> 39 (esta conn)
>
> ==> 39 is the number of http requests in my test plan

I see the problem now.

The httpclient cache key includes the full URL, so only reuses
connections for identical URLs.

It should match on host name, port and protocol.

If you test instead with identical URLs - or loop a single URL - it
should work the same as HC3.1
That's why I did not spot it earlier.

I'll work on a fix now.

>
>> [I think we need to fix this before releasing 2.5.1]
>>
>
>
> Yes sure.
>
>
>>
>>> HTTP conversations show Keep-Alive header (HC3 and HC4)
>>>
>>> I suppose that is a close keep alive connection problem with JMeter.
>>> Perhaps 2 issues are linked?
>>>
>> Dunno yet.
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org


Re: Lots of CLOSE_WAIT with HC4 HTTP implementation

Posted by Milamber <mi...@apache.org>.

Le 21/09/2011 23:13, Milamber a ecrit :
>
> Le 21/09/2011 22:42, sebb a ecrit :
>   
>> On 21 September 2011 22:29, Milamber <mi...@apache.org> wrote:
>>   
>>     
>>> [snip]
>>>
>>> I make a tcp dump and analyze with wireshark.
>>> With HC3.1 : 0-42 secs : 43 TCP conversations (inside several HTTP GET
>>> and response)
>>> With HC4.1 : 0-44 secs : 3011 TCP conversations (inside one HTTP GET and
>>> one response)
>>>     
>>>       
>> Do you mean that each HC4.1 conversation only contains a single
>> request/response?
>>   
>>     
> Yes a single request/response
>   
Mistake : HC4 conversation (follow tcp stream) show multiple GET / for
the same ressource (always same)

More precisions with the new test case (1 thread/39 request/30sec duration)

===
Tcp dump With HC4 (39 conn esta):
60 conversations.

Each conversations show multiple GET /imagexxx.png (always the same
resource per conversation)

===

Tcp dump with HC3 (1 conn esta):
1 tcp conversations

All requests in one keep alive connection (it's a CDN server)

===

>   
>> Can you enable debug logging for HTTPHC4Impl ?
>>   
>>     
> Yes I can, I will sent the log in a private mail
> see end of log : one user but lot of:
> 2011/09/22 01:06:56 DEBUG - jmeter.protocol.http.sampler.HTTPHC4Impl:
> Thread Finished
> 2011/09/22 01:06:56 DEBUG - jmeter.protocol.http.sampler.HTTPHC4Impl:
> Thread Finished
>
>
>   
>> This should show if the clients are being reused or not.
>>
>> I suggest you reduce thread and loop counts, or the log file will be very big.
>>   
>>     
> Done: 1 thread, 1 sec ramp up, 30 secs duration
>
> Starting the test @ Thu Sep 22 01:06:25 CEST 2011 (1316646385910)
> Waiting for possible shutdown message on port 4445
> summary +   188 in   3,7s =   50,9/s Avg:    18 Min:     8 Max:   113
> Err:     0 (0,00%)
> summary +  1697 in  26,1s =   65,1/s Avg:    14 Min:     8 Max:   173
> Err:     0 (0,00%)
> summary =  1885 in  29,8s =   63,3/s Avg:    15 Min:     8 Max:   173
> Err:     0 (0,00%)
> Tidying up ...    @ Thu Sep 22 01:06:56 CEST 2011 (1316646416091)
> ... end of run
>
>
>
> netstat -tplna| grep java | grep ESTA | wc -l
> 39 (esta conn)
>
> ==> 39 is the number of http requests in my test plan
>
>
>   
>> [I think we need to fix this before releasing 2.5.1]
>>   
>>     
>
> Yes sure.
>
>
>   
>>   
>>     
>>> HTTP conversations show Keep-Alive header (HC3 and HC4)
>>>
>>> I suppose that is a close keep alive connection problem with JMeter.
>>> Perhaps 2 issues are linked?
>>>     
>>>       
>> Dunno yet.
>>
>>   
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org


Re: Lots of CLOSE_WAIT with HC4 HTTP implementation

Posted by Milamber <mi...@apache.org>.

Le 21/09/2011 22:42, sebb a ecrit :
> On 21 September 2011 22:29, Milamber <mi...@apache.org> wrote:
>   
>> [snip]
>>
>> I make a tcp dump and analyze with wireshark.
>> With HC3.1 : 0-42 secs : 43 TCP conversations (inside several HTTP GET
>> and response)
>> With HC4.1 : 0-44 secs : 3011 TCP conversations (inside one HTTP GET and
>> one response)
>>     
> Do you mean that each HC4.1 conversation only contains a single
> request/response?
>   

Yes a single request/response

> Can you enable debug logging for HTTPHC4Impl ?
>   

Yes I can, I will sent the log in a private mail
see end of log : one user but lot of:
2011/09/22 01:06:56 DEBUG - jmeter.protocol.http.sampler.HTTPHC4Impl:
Thread Finished
2011/09/22 01:06:56 DEBUG - jmeter.protocol.http.sampler.HTTPHC4Impl:
Thread Finished


> This should show if the clients are being reused or not.
>
> I suggest you reduce thread and loop counts, or the log file will be very big.
>   

Done: 1 thread, 1 sec ramp up, 30 secs duration

Starting the test @ Thu Sep 22 01:06:25 CEST 2011 (1316646385910)
Waiting for possible shutdown message on port 4445
summary +   188 in   3,7s =   50,9/s Avg:    18 Min:     8 Max:   113
Err:     0 (0,00%)
summary +  1697 in  26,1s =   65,1/s Avg:    14 Min:     8 Max:   173
Err:     0 (0,00%)
summary =  1885 in  29,8s =   63,3/s Avg:    15 Min:     8 Max:   173
Err:     0 (0,00%)
Tidying up ...    @ Thu Sep 22 01:06:56 CEST 2011 (1316646416091)
... end of run



netstat -tplna| grep java | grep ESTA | wc -l
39 (esta conn)

==> 39 is the number of http requests in my test plan


> [I think we need to fix this before releasing 2.5.1]
>   


Yes sure.


>   
>> HTTP conversations show Keep-Alive header (HC3 and HC4)
>>
>> I suppose that is a close keep alive connection problem with JMeter.
>> Perhaps 2 issues are linked?
>>     
> Dunno yet.
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org


Re: Lots of CLOSE_WAIT with HC4 HTTP implementation

Posted by sebb <se...@gmail.com>.
On 21 September 2011 22:29, Milamber <mi...@apache.org> wrote:
> Hello,
>
> Sorry, but the problem don't seems resolve.
>
> Today, I try a load test on a Content Delivery Network (CDN) with HC3.1
> vs HC4 with last JMeter trunk (r1173449).
>
> My script :
> Test only static resources (gif, png, jpeg) with direct HTTP Request
> 100 users
> Ramp up : 100 secs
> Duration test : 300 secs (5min)
> Each iteration execute 39 HTTP requests
> HTTP requests : Keep Alive true
>
>
> I have 2 issues (on 8 same tests: 4 HC3.1 and 4 HC4.1) :
>
> *_Issue 1_*
> With HC 3.1 : always no error
> With HC 4.1 : always some errors at the beginning of load test
>
> Stack trace (on view result tree: response data) is :
> org.apache.http.NoHttpResponseException: The target server failed to respond
>    at
> org.apache.http.impl.conn.DefaultResponseParser.parseHead(DefaultResponseParser.java:101)
>    at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:252)
>    at
> org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:281)
>    at
> org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:247)
>    at
> org.apache.http.impl.conn.AbstractClientConnAdapter.receiveResponseHeader(AbstractClientConnAdapter.java:219)
>    at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:298)
>    at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
>    at
> org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:645)
>    at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:464)
>    at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
>    at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:265)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1010)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:996)
>    at
> org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:383)
>    at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:276)
>    at java.lang.Thread.run(Thread.java:722)
>
>
> HC 4 Summariser (begin) :
> summary +    55 in   2,2s =   24,9/s Avg:    71 Min:    15 Max:  1677
> Err:     0 (0,00%)
> summary +  5027 in  30,0s =  167,5/s Avg:   103 Min:     1 Max:  1816
> Err:    14 (0,28%)
> summary =  5082 in  32,2s =  157,8/s Avg:   103 Min:     1 Max:  1816
> Err:    14 (0,28%)
> summary +  5013 in  31,4s =  159,7/s Avg:   283 Min:     2 Max:  3500
> Err:    11 (0,22%)
> summary = 10095 in  62,2s =  162,3/s Avg:   192 Min:     1 Max:  3500
> Err:    25 (0,25%)
> summary +  5075 in  31,6s =  160,7/s Avg:   449 Min:    37 Max:  7999
> Err:     0 (0,00%)
> summary = 15170 in  92,2s =  164,5/s Avg:   278 Min:     1 Max:  7999
> Err:    25 (0,16%)
> summary +  4984 in  34,8s =  143,2/s Avg:   587 Min:    40 Max: 11028
> Err:     0 (0,00%)
> summary = 20154 in 122,2s =  164,9/s Avg:   355 Min:     1 Max: 11028
> Err:    25 (0,12%)
> */_
> Issue 2 :_/*
>
> With HC3.1 after ramp up:
>  netstat -tplna|grep java|grep ESTA|wc -l
> 100
>
> With HC4.1 at beginning and after ramp up :
> netstat -tplna| grep java | grep ESTA | wc -l
> 1145 (value change between ~1000-1150)
>
> I make a tcp dump and analyze with wireshark.
> With HC3.1 : 0-42 secs : 43 TCP conversations (inside several HTTP GET
> and response)
> With HC4.1 : 0-44 secs : 3011 TCP conversations (inside one HTTP GET and
> one response)

Do you mean that each HC4.1 conversation only contains a single
request/response?

Can you enable debug logging for HTTPHC4Impl ?
This should show if the clients are being reused or not.

I suggest you reduce thread and loop counts, or the log file will be very big.

[I think we need to fix this before releasing 2.5.1]

> HTTP conversations show Keep-Alive header (HC3 and HC4)
>
> I suppose that is a close keep alive connection problem with JMeter.
> Perhaps 2 issues are linked?

Dunno yet.

> Milamber
>
>
> Le 24/08/2011 11:40, sebb a ecrit :
>> On 24 August 2011 02:43, sebb <se...@gmail.com> wrote:
>>
>>> Looks like HTTPHC4Impl is not reusing HttpClient instances.
>>>
>>> It should only create one per thread per unique URL + some other fields.
>>>
>>> It seems not to be finding the previously created instances, so it
>>> creates a new one for every sample.
>>> Not sure why yet; probably something simple.
>>>
>> Very simple.
>>
>> The equals() method was returning false if the other object was the
>> correct type, instead of returning false for the incorrect type.
>> So the hash keys never matched.
>>
>> Nightly builds from r1160957 will have the fix.
>>
>>
>>> However the code does at least seem to be closing the connections at
>>> end of thread.
>>>
>>> On 23 August 2011 17:13, Milamber <mi...@apache.org> wrote:
>>>
>>>> [snip]
>>>>
>>>>>> I believe is a HTTPClient issue, on close connection?
>>>>>> (http://www.sunmanagers.org/pipermail/summaries/2006-January/007068.html)
>>>>>>
>>>>>>
>>>>> I think it's more likely to be that JMeter is not tidying up the HC4
>>>>> connections properly.
>>>>>
>>>>> Are you using Keep-Alive?
>>>>>
>>>>>
>>>> Yes.
>>>>
>>>>
>>>>> Can you reproduce the problem with a simpler test case, e.g. one that
>>>>> could be run against a local server.
>>>>>
>>>>>
>>>> Yes on my laptop (Debian 6 / 64 bits / openjdk 1.6u18)
>>>>
>>>> in attachment JMeter testcase.
>>>>
>>>> With HC4 impl:
>>>> summary =  2590 in  72.4s =   35.8/s Avg:   994 Min:   487 Max:  4806
>>>> Err:     0 (0.00%)
>>>>
>>>> Stats at ~ 72secs :
>>>> netstat -tuplna|grep java |wc -l;
>>>> 1494
>>>> netstat -tuplna|grep java|grep ESTA|wc -l;
>>>> 167
>>>> netstat -tplnau|grep java|grep CLOSE_WAIT|wc -l;
>>>> 1337
>>>>
>>>>
>>>> With HC3 impl:
>>>> summary =  4498 in  83.2s =   54.1/s Avg:   448 Min:   246 Max:  2489
>>>> Err:     0 (0.00%)
>>>>
>>>> Stats at ~83 secs:
>>>> netstat -tuplna|grep java |wc -l;
>>>> 61
>>>> netstat -tuplna|grep java|grep ESTA|wc -l;
>>>> 60
>>>> netstat -tplnau|grep java|grep CLOSE_WAIT|wc -l;
>>>> 0
>>>>
>>>> NB: more requests in same time with HC3.
>>>> NB2: HC3 ESTABLISHED connections is lesser than HC4 (60 users in JMeter
>>>> scripts)
>>>>
>>>>
>>>> Milamber
>>>>
>>>>
>>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org


Re: Lots of CLOSE_WAIT with HC4 HTTP implementation

Posted by Milamber <mi...@apache.org>.
Hello,

Sorry, but the problem don't seems resolve.

Today, I try a load test on a Content Delivery Network (CDN) with HC3.1
vs HC4 with last JMeter trunk (r1173449).

My script :
Test only static resources (gif, png, jpeg) with direct HTTP Request
100 users
Ramp up : 100 secs
Duration test : 300 secs (5min)
Each iteration execute 39 HTTP requests
HTTP requests : Keep Alive true


I have 2 issues (on 8 same tests: 4 HC3.1 and 4 HC4.1) :

*_Issue 1_*
With HC 3.1 : always no error
With HC 4.1 : always some errors at the beginning of load test

Stack trace (on view result tree: response data) is :
org.apache.http.NoHttpResponseException: The target server failed to respond
    at
org.apache.http.impl.conn.DefaultResponseParser.parseHead(DefaultResponseParser.java:101)
    at
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:252)
    at
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:281)
    at
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:247)
    at
org.apache.http.impl.conn.AbstractClientConnAdapter.receiveResponseHeader(AbstractClientConnAdapter.java:219)
    at
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:298)
    at
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
    at
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:645)
    at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:464)
    at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
    at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
    at
org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:265)
    at
org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
    at
org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1010)
    at
org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:996)
    at
org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:383)
    at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:276)
    at java.lang.Thread.run(Thread.java:722)


HC 4 Summariser (begin) :
summary +    55 in   2,2s =   24,9/s Avg:    71 Min:    15 Max:  1677
Err:     0 (0,00%)
summary +  5027 in  30,0s =  167,5/s Avg:   103 Min:     1 Max:  1816
Err:    14 (0,28%)
summary =  5082 in  32,2s =  157,8/s Avg:   103 Min:     1 Max:  1816
Err:    14 (0,28%)
summary +  5013 in  31,4s =  159,7/s Avg:   283 Min:     2 Max:  3500
Err:    11 (0,22%)
summary = 10095 in  62,2s =  162,3/s Avg:   192 Min:     1 Max:  3500
Err:    25 (0,25%)
summary +  5075 in  31,6s =  160,7/s Avg:   449 Min:    37 Max:  7999
Err:     0 (0,00%)
summary = 15170 in  92,2s =  164,5/s Avg:   278 Min:     1 Max:  7999
Err:    25 (0,16%)
summary +  4984 in  34,8s =  143,2/s Avg:   587 Min:    40 Max: 11028
Err:     0 (0,00%)
summary = 20154 in 122,2s =  164,9/s Avg:   355 Min:     1 Max: 11028
Err:    25 (0,12%)
*/_
Issue 2 :_/*

With HC3.1 after ramp up:
 netstat -tplna|grep java|grep ESTA|wc -l
100

With HC4.1 at beginning and after ramp up :
netstat -tplna| grep java | grep ESTA | wc -l
1145 (value change between ~1000-1150)

I make a tcp dump and analyze with wireshark.
With HC3.1 : 0-42 secs : 43 TCP conversations (inside several HTTP GET
and response)
With HC4.1 : 0-44 secs : 3011 TCP conversations (inside one HTTP GET and
one response)

HTTP conversations show Keep-Alive header (HC3 and HC4)

I suppose that is a close keep alive connection problem with JMeter.
Perhaps 2 issues are linked?

Milamber


Le 24/08/2011 11:40, sebb a ecrit :
> On 24 August 2011 02:43, sebb <se...@gmail.com> wrote:
>   
>> Looks like HTTPHC4Impl is not reusing HttpClient instances.
>>
>> It should only create one per thread per unique URL + some other fields.
>>
>> It seems not to be finding the previously created instances, so it
>> creates a new one for every sample.
>> Not sure why yet; probably something simple.
>>     
> Very simple.
>
> The equals() method was returning false if the other object was the
> correct type, instead of returning false for the incorrect type.
> So the hash keys never matched.
>
> Nightly builds from r1160957 will have the fix.
>
>   
>> However the code does at least seem to be closing the connections at
>> end of thread.
>>
>> On 23 August 2011 17:13, Milamber <mi...@apache.org> wrote:
>>     
>>> [snip]
>>>       
>>>>> I believe is a HTTPClient issue, on close connection?
>>>>> (http://www.sunmanagers.org/pipermail/summaries/2006-January/007068.html)
>>>>>
>>>>>           
>>>> I think it's more likely to be that JMeter is not tidying up the HC4
>>>> connections properly.
>>>>
>>>> Are you using Keep-Alive?
>>>>
>>>>         
>>> Yes.
>>>
>>>       
>>>> Can you reproduce the problem with a simpler test case, e.g. one that
>>>> could be run against a local server.
>>>>
>>>>         
>>> Yes on my laptop (Debian 6 / 64 bits / openjdk 1.6u18)
>>>
>>> in attachment JMeter testcase.
>>>
>>> With HC4 impl:
>>> summary =  2590 in  72.4s =   35.8/s Avg:   994 Min:   487 Max:  4806
>>> Err:     0 (0.00%)
>>>
>>> Stats at ~ 72secs :
>>> netstat -tuplna|grep java |wc -l;
>>> 1494
>>> netstat -tuplna|grep java|grep ESTA|wc -l;
>>> 167
>>> netstat -tplnau|grep java|grep CLOSE_WAIT|wc -l;
>>> 1337
>>>
>>>
>>> With HC3 impl:
>>> summary =  4498 in  83.2s =   54.1/s Avg:   448 Min:   246 Max:  2489
>>> Err:     0 (0.00%)
>>>
>>> Stats at ~83 secs:
>>> netstat -tuplna|grep java |wc -l;
>>> 61
>>> netstat -tuplna|grep java|grep ESTA|wc -l;
>>> 60
>>> netstat -tplnau|grep java|grep CLOSE_WAIT|wc -l;
>>> 0
>>>
>>> NB: more requests in same time with HC3.
>>> NB2: HC3 ESTABLISHED connections is lesser than HC4 (60 users in JMeter
>>> scripts)
>>>
>>>
>>> Milamber
>>>
>>>       
>>     
>   


Re: Lots of CLOSE_WAIT with HC4 HTTP implementation

Posted by sebb <se...@gmail.com>.
On 24 August 2011 02:43, sebb <se...@gmail.com> wrote:
> Looks like HTTPHC4Impl is not reusing HttpClient instances.
>
> It should only create one per thread per unique URL + some other fields.
>
> It seems not to be finding the previously created instances, so it
> creates a new one for every sample.
> Not sure why yet; probably something simple.

Very simple.

The equals() method was returning false if the other object was the
correct type, instead of returning false for the incorrect type.
So the hash keys never matched.

Nightly builds from r1160957 will have the fix.

> However the code does at least seem to be closing the connections at
> end of thread.
>
> On 23 August 2011 17:13, Milamber <mi...@apache.org> wrote:
>>
>> [snip]
>>>> I believe is a HTTPClient issue, on close connection?
>>>> (http://www.sunmanagers.org/pipermail/summaries/2006-January/007068.html)
>>>>
>>> I think it's more likely to be that JMeter is not tidying up the HC4
>>> connections properly.
>>>
>>> Are you using Keep-Alive?
>>>
>>
>> Yes.
>>
>>> Can you reproduce the problem with a simpler test case, e.g. one that
>>> could be run against a local server.
>>>
>>
>> Yes on my laptop (Debian 6 / 64 bits / openjdk 1.6u18)
>>
>> in attachment JMeter testcase.
>>
>> With HC4 impl:
>> summary =  2590 in  72.4s =   35.8/s Avg:   994 Min:   487 Max:  4806
>> Err:     0 (0.00%)
>>
>> Stats at ~ 72secs :
>> netstat -tuplna|grep java |wc -l;
>> 1494
>> netstat -tuplna|grep java|grep ESTA|wc -l;
>> 167
>> netstat -tplnau|grep java|grep CLOSE_WAIT|wc -l;
>> 1337
>>
>>
>> With HC3 impl:
>> summary =  4498 in  83.2s =   54.1/s Avg:   448 Min:   246 Max:  2489
>> Err:     0 (0.00%)
>>
>> Stats at ~83 secs:
>> netstat -tuplna|grep java |wc -l;
>> 61
>> netstat -tuplna|grep java|grep ESTA|wc -l;
>> 60
>> netstat -tplnau|grep java|grep CLOSE_WAIT|wc -l;
>> 0
>>
>> NB: more requests in same time with HC3.
>> NB2: HC3 ESTABLISHED connections is lesser than HC4 (60 users in JMeter
>> scripts)
>>
>>
>> Milamber
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org


Re: Lots of CLOSE_WAIT with HC4 HTTP implementation

Posted by sebb <se...@gmail.com>.
Looks like HTTPHC4Impl is not reusing HttpClient instances.

It should only create one per thread per unique URL + some other fields.

It seems not to be finding the previously created instances, so it
creates a new one for every sample.
Not sure why yet; probably something simple.

However the code does at least seem to be closing the connections at
end of thread.

On 23 August 2011 17:13, Milamber <mi...@apache.org> wrote:
>
> [snip]
>>> I believe is a HTTPClient issue, on close connection?
>>> (http://www.sunmanagers.org/pipermail/summaries/2006-January/007068.html)
>>>
>> I think it's more likely to be that JMeter is not tidying up the HC4
>> connections properly.
>>
>> Are you using Keep-Alive?
>>
>
> Yes.
>
>> Can you reproduce the problem with a simpler test case, e.g. one that
>> could be run against a local server.
>>
>
> Yes on my laptop (Debian 6 / 64 bits / openjdk 1.6u18)
>
> in attachment JMeter testcase.
>
> With HC4 impl:
> summary =  2590 in  72.4s =   35.8/s Avg:   994 Min:   487 Max:  4806
> Err:     0 (0.00%)
>
> Stats at ~ 72secs :
> netstat -tuplna|grep java |wc -l;
> 1494
> netstat -tuplna|grep java|grep ESTA|wc -l;
> 167
> netstat -tplnau|grep java|grep CLOSE_WAIT|wc -l;
> 1337
>
>
> With HC3 impl:
> summary =  4498 in  83.2s =   54.1/s Avg:   448 Min:   246 Max:  2489
> Err:     0 (0.00%)
>
> Stats at ~83 secs:
> netstat -tuplna|grep java |wc -l;
> 61
> netstat -tuplna|grep java|grep ESTA|wc -l;
> 60
> netstat -tplnau|grep java|grep CLOSE_WAIT|wc -l;
> 0
>
> NB: more requests in same time with HC3.
> NB2: HC3 ESTABLISHED connections is lesser than HC4 (60 users in JMeter
> scripts)
>
>
> Milamber
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org


Re: Lots of CLOSE_WAIT with HC4 HTTP implementation

Posted by Milamber <mi...@apache.org>.
[snip]
>> I believe is a HTTPClient issue, on close connection?
>> (http://www.sunmanagers.org/pipermail/summaries/2006-January/007068.html)
>>     
> I think it's more likely to be that JMeter is not tidying up the HC4
> connections properly.
>
> Are you using Keep-Alive?
>   

Yes.

> Can you reproduce the problem with a simpler test case, e.g. one that
> could be run against a local server.
>   

Yes on my laptop (Debian 6 / 64 bits / openjdk 1.6u18)

in attachment JMeter testcase.

With HC4 impl:
summary =  2590 in  72.4s =   35.8/s Avg:   994 Min:   487 Max:  4806
Err:     0 (0.00%)

Stats at ~ 72secs :
netstat -tuplna|grep java |wc -l;
1494
netstat -tuplna|grep java|grep ESTA|wc -l;
167
netstat -tplnau|grep java|grep CLOSE_WAIT|wc -l;
1337


With HC3 impl:
summary =  4498 in  83.2s =   54.1/s Avg:   448 Min:   246 Max:  2489
Err:     0 (0.00%)

Stats at ~83 secs:
netstat -tuplna|grep java |wc -l;
61
netstat -tuplna|grep java|grep ESTA|wc -l;
60
netstat -tplnau|grep java|grep CLOSE_WAIT|wc -l;
0

NB: more requests in same time with HC3.
NB2: HC3 ESTABLISHED connections is lesser than HC4 (60 users in JMeter
scripts)


Milamber