Mailing-List: contact user-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "JMeter Users List" <user@jmeter.apache.org>
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
In-Reply-To: <ab9e2783cad0420e85d867adda60ef77@NZWLGEXC13.equinox.co.nz>
References: <caba8baa12004fba963b34a0b2ee7209@NZWLGEXC13.equinox.co.nz>
	<1399994157.56516.YahooMailNeo@web140104.mail.bf1.yahoo.com>
	<ab9e2783cad0420e85d867adda60ef77@NZWLGEXC13.equinox.co.nz>
Date: Wed, 14 May 2014 12:28:40 +0200
Message-ID: 
 <CAH9fUpbMhpfOFeHDu40Tg9YSV1i1fVK8_RbZ1iUY9RWNqJyisg@mail.gmail.com>
Subject: Re: createSSLContext CPU issue
From: Philippe Mouawad <p.mouawad@ubik-ingenierie.com>
To: JMeter Users List <user@jmeter.apache.org>
Content-Type: multipart/alternative; boundary=bcaec51f9663e3764704f959a41e

--bcaec51f9663e3764704f959a41e
Content-Type: text/plain; charset=ISO-8859-1

Hello,
Note that JMeter 2.11 is not compatible with JAVA 8 (which was released
after it), there is a fixed bug.

Next release will be, trunk is if you want to give it a try through nightly
build.

Regards
Philippe M.
@philmdot <https://twitter.com/philmdot>


UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>

UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>


On Wed, May 14, 2014 at 12:11 PM, Stephen Townshend <
stephen.townshend@equinox.co.nz> wrote:

>
> Hi Kiran,
>
> I am 100% certain that nothing else is calling HTTPS - inside Process
> Monitor we're filtering to only look at Jmeter's java.exe process and that
> was the one making all the SSL calls before I changed it to the HTTP3.1
> implementation from HTTP4.
>
> Memory was also not running out until after CPU hit 100%, at which point
> memory would fill up until the system froze.
>
> Looks like this issue was previously identified in Jmeter 2.9 and was
> fixed. I need to test it out on Jmeter 2.10 and/or 2.11 to see if I can
> reproduce the issue when I am next able. I thought I had seen it in 2.11
> but it is entirely possible I got confused between this and the other issue
> I was having (Beanshell PreProcessors causing a memory leak).
>
>
> -----Original Message-----
> From: Kiran Badi [mailto:kiranbadi@yahoo.com]
> Sent: Wednesday, 14 May 2014 3:16 a.m.
> To: JMeter Users List; jmeter-user@jakarta.apache.org
> Subject: Re: createSSLContext CPU issue
>
> Can you take the trace outside the JMeter with either fiddler or browser
> dev tool to see if there is any call going with https. From below trace I
> can see that its jmeter which is trying to use SSL. Since its trying to
> read it from the file/disk and probably your box is running very hot, its
> failing. Are you sure that you are not running out memory on VM's ?
>
>
> if Jmeter is not making a https call then something in your box is doing
> it.
>
> With Regards,
> Kiran Badi
> Email:kiranbadi@yahoo.com
> Ph- US-(+01)6462013101
>
>
> ________________________________
>  From: Stephen Townshend <stephen.townshend@equinox.co.nz>
> To: "jmeter-user@jakarta.apache.org" <jmeter-user@jakarta.apache.org>
> Sent: Monday, May 12, 2014 10:03 PM
> Subject: createSSLContext CPU issue
>
>
> Hi all,
>
> I'm currently on a performance testing assignment for a client who has a
> public website sitting within a virtual infrastructure. I've been given a
> virtual server (running Windows Server 2008) to run my tests from with
> access to the system under test.
>
> The issue is that after a period of time running my load tests the CPU
> suddenly spikes from ~50% or less up to 100% and never recovers. Next what
> happens is that every test I run after that failure will also consume CPU
> at a much higher rate than before, quickly become overloaded again and
> eventually Jmeter will crash or I have to stop the test.
>
> I've been using VisualVM to analyse the Jmeter JVM during my test runs.
>
> My questions are (relating to the detail below):
>
> -          Taking a thread dump there is a whole lot of activity around
> SSL connections but the test I'm running has no HTTPS requests at all -
> they're all plain HTTP - so why are any SSL connections being made at all?
>
> -          Why is it taking up all the CPU?
>
> -          I'm also seeing thousands of CLOSE_WAIT connections when a test
> is running, they continue to exist even once the JVM has been closed down -
> why is that?
>
> I've never had to install certificates before even when testing HTTPS
> traffic.
>
> JVM monitoring of a test which suddenly goes to 100% CPU:
>
> http://i.imgur.com/lmrfaoH.png
>
> And an example of a follow up test where it quickly hits 100% again:
>
> http://i.imgur.com/929YQXh.png
>
> A CPU sample in VisualVM when it starts failing showing it taking a lot of
> time on createSSLContext():
>
> http://i.imgur.com/YOjBeqg.png
>
> -
> Thread dump of JVM when test is failing - it looks like it is reading
> certificate files?
>
> "Thread-16959" prio=6 tid=0x0000000013b2a800 nid=0x8fb4 runnable
> [0x000000009ef8e000]
>    java.lang.Thread.State: RUNNABLE
>         at java.io.FileInputStream.read0(Native Method)
>         at java.io.FileInputStream.read(Unknown Source)
>         at java.io.DataInputStream.readInt(Unknown Source)
>         at sun.security.provider.JavaKeyStore.engineLoad(Unknown Source)
>         - locked <0x00000007fa3193c8> (a java.util.Hashtable)
>         at sun.security.provider.JavaKeyStore$JKS.engineLoad(Unknown
> Source)
>         at java.security.KeyStore.load(Unknown Source)
>         at
> sun.security.ssl.TrustManagerFactoryImpl.getCacertsKeyStore(Unknown Source)
>         at sun.security.ssl.TrustManagerFactoryImpl.engineInit(Unknown
> Source)
>         at javax.net.ssl.TrustManagerFactory.init(Unknown Source)
>         at
> org.apache.http.conn.ssl.SSLSocketFactory.createSSLContext(SSLSocketFactory.java:229)
>         at
> org.apache.http.conn.ssl.SSLSocketFactory.createDefaultSSLContext(SSLSocketFactory.java:358)
>         at
> org.apache.http.conn.ssl.SSLSocketFactory.getSocketFactory(SSLSocketFactory.java:175)
>         at
> org.apache.http.impl.conn.SchemeRegistryFactory.createDefault(SchemeRegistryFactory.java:49)
>         at
> org.apache.http.impl.client.AbstractHttpClient.createClientConnectionManager(AbstractHttpClient.java:306)
>         at
> org.apache.http.impl.client.AbstractHttpClient.getConnectionManager(AbstractHttpClient.java:466)
>         - locked <0x00000007fa318398> (a
> org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl$4)
>         at
> org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.setupClient(HTTPHC4Impl.java:495)
>         at
> org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:230)
>         at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
>         at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase$ASyncSample.call(HTTPSamplerBase.java:1804)
>         at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase$ASyncSample.call(HTTPSamplerBase.java:1772)
>         at java.util.concurrent.FutureTask.run(Unknown Source)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> Source)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source)
>         at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase$1$1.run(HTTPSamplerBase.java:1240)
>         at java.lang.Thread.run(Unknown Source)
>
> I'm also seeing thousands of CLOSE_WAIT connections when a test is
> running, they continue to exist even once the JVM has been closed down.
>
> Stephen Townshend, Performance Engineer, Equinox Limited,
> http://www.equinox.co.nz/
> Address Level 5, Shortland Chambers, 70 Shortland Street, PO Box 3903,
> Auckland 1140, New Zealand
> Contact stephen.townshend@equinox.co.nz<mailto:
> stephen.townshend@equinox.co.nz>, Phone: +64 9 307 9450, DDI: +64 9 307
> 9007, Mobile: +64 22 6051 423
>
> Please consider the environment before printing this e-mail.
>
> ___________________________________________________________________________________
> This e-mail message and any attachments contain information that is
> confidential and may be subject
> to legal privilege. If you are not the intended recipient, you must not
> peruse, use, pass on or copy this
> message or any attachments. If you have received this e-mail in error,
> please notify us by return e-mail
> and erase all copies of this message including any attachments. Thank you.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>

--bcaec51f9663e3764704f959a41e--