1
votes

Scenario taking into account login user->Navigate to Page 01->hold the user for 5min->Logout user

Scripted as below:

  • Navigate to the Home page
  • The user is logged in (Assertion for login verification over some text on the dashboard)
  • Dashboard appears
  • Navigate to Page 01 (Assertion Page 01 content)
  • Logout (Constant Timer added for 5min and Assertion for logout to verify home page is redirected)

Step Up thread configuration has been kept this way:

Stepping Thread Group thread/ramp-up configuration

For achieving this scenario distributed system was implemented as follows:

  • Master(My own machine 8 GB Ram and Core 2 Duo Processor)
  • 2 slaves machines (8 GB Ram each and I7 and Core 2 Duo Processors)

  • Thread: jp@gc - Stepping Thread Group

The server has been configured as below:

  • 2 EC2 Instance (16 GB Ram each)
  • 1 Load Balancer
  • 1 RDS Instance

Note: Instance is auto scaled at 60% CPU Utilization.

While executing the script for 500 concurrent users using stepping thread on Non-GUI mode, below list of error is appearing on the dashboard report

  • 504/Gateway Time-out
  • Non HTTP response code: java.net.SocketException/Non HTTP response message: Connection reset
  • Assertion as logout failed

Could someone help me out to know why these are appearing? when I checked the Load Balancer 504/Gateway Time-out was not appearing there? I was trying to track these error but was not able to figure it out why these along with other two errors are appearing. When the same script is executed for 10 users not error is appearing on GUI mode.

While the same script when executed for 100-250 concurrent user it works pretty well when no such above error.

1

1 Answers

0
votes

If the issue doesn't happen for 250 virtual users and happens for 500 - it's definitely the bottleneck caused by increased load, you just need to find out the reason.

  1. Make sure to have DNS Cache Manager added to your Test Plan otherwise you may run into the situation when the load goes to one server only
  2. Set up monitoring of your EC2 instances to ensure that they have enough headroom to operate in terms of CPU, RAM, Network, etc. You can use Amazon CloudWatch or JMeter PerfMon Plugin for this.
  3. You might want to re-run the test with profiling tool telemetry enabled - this way you will be able to see where application spends the majority of time
  4. Inspect the configuration of your application servers, databases, etc. as it might be configuration issue of the middleware
  5. Be aware that according to JMeter Best Practices you should always be using the latest JMeter version so consider migrating to JMeter 5.0 (or whatever is the latest version available at JMeter Downloads page) on as soon as possible.