Thanks Vladimir.
@Felix, with http-client-4.5.2 and this line uncommented:
// FIXME when 4.5.2 is released, see
https://issues.apache.org/jira/browse/HTTPCORE-397
((AbstractHttpClient)
httpClient).setReuseStrategy(DefaultClientConnectionReuseStrategy.INSTANCE);
I don't reproduce the Connect Timeout issue due to keep alive.
Note this is the version I am testing and that face the issue. So there is
another problem.
Regards
Philippe
On Sun, Jan 31, 2016 at 8:58 PM, Vladimir Sitnikov <
[email protected]> wrote:
> JFR confirms the issue is not related with GC/locking/excessive processing.
>
> I wonder if tcp dump/wireshark would help to analyze the difference.
>
> Findings so far:
> 1)
> org.apache.jmeter.protocol.http.parser.LagartoBasedHtmlParser#getEmbeddedResourceURLs
> is converting response bytes to String (see [1]).
> It is better to use SampleResult#getResponseDataAsString since the
> latter would cache the string, thus eliminate repeated utf-8 decoding.
>
> 2) In 3.0
> org.apache.jmeter.protocol.http.control.HC4CookieHandler#getCookiesForUrl
> is a little bit more involved since cookieSpec.match delegates to
> org.apache.http.impl.cookie.DefaultCookieSpec.match(Cookie,
> CookieOrigin) -> CookieSpecBase.match ->
> PublicSuffixDomainFilter.match ->...
> In 2.14 it is much simpler.
> In 3.0, DefaultCookieSpec.match accounts for 3% of all cpu time.
>
> I do not see how those issues could result in "connect timeout" though.
>
> [1]:
> https://github.com/apache/jmeter/blob/9a1b9a02c7593553cb6047bddcfbccb79ec72fc9/src/protocol/http/org/apache/jmeter/protocol/http/parser/LagartoBasedHtmlParser.java#L210
>
> Vladimir
>
--
Cordialement.
Philippe Mouawad.
