Hello, Regarding current trunk version, loading of cacert will happen: 1 time per thread per each instance of different proxy settings and each protocol and each authority
so for a test that does not use proxy with only http , you will get: - Number of threads x 1 loading of cacerts at first sample for a test that does not use proxy and uses http+https: - Number of threads x 2 loading of cacerts at first sample So with nightly build you should not face anymore your issue. So I think you are facing fixed bug: - https://issues.apache.org/bugzilla/show_bug.cgi?id=55023 Make a test with 2.11 + Java 7 and give us feedback (it would be nice). Thanks On Wed, May 14, 2014 at 12:28 PM, Philippe Mouawad < [email protected]> wrote: > 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] >> >> > > -- Cordialement. Philippe Mouawad. Ubik-Ingénierie UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/> UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>
