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
