Load testing of 100 user using jmeter on asp.net application giving error on jquery

Question

I am doing load testing on my asp.net application using jmeter for only 100 user.

I am having jquery on page "Scripts/jquery.min.js" Jquery is present in folder. The error is as following on 20% of user.

`sample result :- Thread Name: Thread Group 1-25 Sample Start: 2014-07-31 11:45:43 IST Load time: 189003 Latency: 0 Size in bytes: 2000 Headers size in bytes: 0 Body size in bytes: 2000 Sample Count: 1 Error Count: 1 Response code: Non HTTP response code: javax.net.ssl.SSLHandshakeException Response message: Non HTTP response message: Remote host closed connection during handshake

Response headers:

HTTPSampleResult fields: ContentType: DataEncoding: null`

request - GET https://www.mydomain.com/Scripts/jquery.min.js

[no cookies]

Request Headers: Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8 User-Agent: Mozilla/5.0(WindowsNT6.2;WOW64;rv:21.0)Gecko/20100101Firefox/21.0 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8

responcedata - javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:436) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:643) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:481) at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:298) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase$ASyncSample.call(HTTPSamplerBase.java:1826) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase$ASyncSample.call(HTTPSamplerBase.java:1794) 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:1257) at java.lang.Thread.run(Unknown Source) Caused by: java.io.EOFException: SSL peer shut down incorrectly at sun.security.ssl.InputRecord.read(Unknown Source) ... 21 more

Note : I have tried 100 user. 80 user haven't get this error rest 20 user get this error. Server is very much strong. it is on cloud server with high configuration. I am trying only 100 user and only 80% is success rate. 20% I am getting failure response.

Please share your idea.

Answer 1

Try setting https.use.cached.ssl.context=false in jmeter.properties file. It can be also overriden in user.properties file or set for a single run via -J command line argument as

jmeter -Jhttps.use.cached.ssl.context=false -n -t /path/to/your/test/plan.jmx -l /path/to/results.jtl

See Apache JMeter Properties Customization Guide for properties configuration advanced information.

Answer 2

The SSL handshake failure in the stack trace can be due to either the client side and/or the server side. To find which one is responsible, you could use wireshark (or other network packet sniffer) to capture all the packets and find a TCP session that has the failed SSL handshake.

Finding a TCP session among all the captured packet may take some work. One trick is to export all the packet summary into a text file and write a script to search for the "bad" tcp session. You may be happy that you come to know more about SSL than ever ;-)