jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Sitnikov <sitnikov.vladi...@gmail.com>
Subject Re: Important Regression in nightly build compared to 2.13 or r1715087
Date Sun, 31 Jan 2016 19:58:01 GMT
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

Mime
View raw message