I am running a test plan with 8,000 concurrent users in a Distributed Environment(20 Slaves and One Master) on Jmeter.

A few (approx 20-30) requests are not getting any response for a long time (approx an hour). I waited for a long time to allow the pending requests to complete, but Jmeter threw an exception with "Socket.timeout".

Can any one help me in understanding what the problem is. Am I lagging somewhere to understand the possible reason?

3 Answers 3


When you are doing a load test on an application, there is a lot that you have to take into consideration,

  • CPU utilization over time with consistent load.
  • RAM utilization over time with consistent load.
  • Disk I/O utilization over time with consistent load.
  • Network I/O utilization over time with consistent load.

Not just the server's CPU and RAM but its network and disk I/O are also important. You also need to see what amount of requests choke up the port that your application is using for communication. CPU and RAM will be utilized if the request reaches them for execution. What if the port is not able to handle the amount of load you are hitting it with? In that case it will throw errors like socket timeouts. Each request has a certain execution life time (connection timeout) within which if the response is not received, you are bound to get a timeout error. So check your port capacity and the disk and network I/O.

  • how much time jmeter waits to get the responce from server? May 9, 2016 at 5:17
  • 1
    @sameer joshi, I'm not really sure if Jmeter has a default Connect Timeout set, but HTTP requests usually have some timeout like 30s or 60s. Although you can specify Connect Timeout in Jmeter in the HTTP Request sampler. May 9, 2016 at 5:27

This is a network constraint over which you may not have any control. Do you know after what time you get this error? You could play with Timeouts section on HTTP Request Sample and keep it higher than the time which causes timeout error.

  • We have set timeouts in Jmeter to infinite, I got this error in Jmeter after 25-30 Minutes after script begun.
    – Pravin W
    Apr 19, 2016 at 5:04

This might be because some of application requests are taking too long to execute, holding the application server’s threads busy, and not allowing the resources to be used by incoming requests.

Try the running the test with 4000 concurrent users, then 6000 users and so on. Check at number of request you are getting this error.You must verify Apache logs or IIS logs and look for errors in the error and access logs. Monitor CPU and memory utilization and try to find bottleneck and fine tune to obtain desired results.

  • I have already tried with 2K, 4K, 6K, 8K requests. For these it worked fine, I did not get any error. But whenever I am putting extra load, few threads start to stuck
    – Pravin W
    Apr 19, 2016 at 5:05
  • What could be the reason for these last few pending requests, As I am seeing SQL server CPU % utilization is too small (approx 4-5 %) when this happens. App server CPU is also too small as compared to the CPU consumption when script of 10K concurrent users starts. Also, active DB connections are also too less at this point of time. So what is stopping these requests to get serve? Is there any thing missing in JMeter? Is my number of slaves in distributed testing is less (20 Slaves are there as of now for 10K concurrent users)?
    – Pravin W
    Apr 19, 2016 at 5:15
  • 1
    in that case u would u would need to up the application server's hardware configuration. The application server may not able to take up this much requests. As your application's resource utilization is optimal. application server with current hardware configuration isn't able to process this much request. please check Apache logs or IIS logs to get more clarity on this
    – neha bedi
    Apr 19, 2016 at 6:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.