jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <p.moua...@ubik-ingenierie.com>
Subject Re: createSSLContext CPU issue
Date Thu, 15 May 2014 20:08:12 GMT
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 <
p.mouawad@ubik-ingenierie.com> 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 <
> 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
>>
>>
>
>


-- 
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie

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

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message