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 < [email protected]> 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:[email protected]] > Sent: Wednesday, 14 May 2014 3:16 a.m. > To: JMeter Users List; [email protected] > 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:[email protected] > Ph- US-(+01)6462013101 > > > ________________________________ > From: Stephen Townshend <[email protected]> > To: "[email protected]" <[email protected]> > 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 [email protected]<mailto: > [email protected]>, 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: [email protected] > For additional commands, e-mail: [email protected] > >
