jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Townshend <>
Subject RE: createSSLContext CPU issue
Date Tue, 13 May 2014 03:40:48 GMT
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:

And an example of a follow up test where it quickly hits 100% again:

A CPU sample in VisualVM when it starts failing showing it taking a lot of time on createSSLContext():

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 Method)
        at Source)
        at Source)
        at Source)
        - locked <0x00000007fa3193c8> (a java.util.Hashtable)
        at$JKS.engineLoad(Unknown Source)
        at Source)
        at Source)
        at Source)
        at Source)
        at org.apache.http.conn.ssl.SSLSocketFactory.createSSLContext(
        at org.apache.http.conn.ssl.SSLSocketFactory.createDefaultSSLContext(
        at org.apache.http.conn.ssl.SSLSocketFactory.getSocketFactory(
        at org.apache.http.impl.conn.SchemeRegistryFactory.createDefault(
        at org.apache.http.impl.client.AbstractHttpClient.createClientConnectionManager(
        at org.apache.http.impl.client.AbstractHttpClient.getConnectionManager(
        - locked <0x00000007fa318398> (a org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl$4)
        at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.setupClient(
        at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(
        at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(
        at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase$
        at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase$
        at Source)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$ Source)
        at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase$1$
        at 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.

Update: Looking at process monitor it is reading the file C:\Program Files\Java\jdk1.7.0_55\jre\lib\security\cacerts
thousands of times, might be related.

Stephen Townshend, Performance Engineer, Equinox Limited,
Address Level 5, Shortland Chambers, 70 Shortland Street, PO Box 3903, Auckland 1140, New
Contact<>, 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
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.

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