Request fails when active user count is high

HI,

I am trying to load test a scenario (Oauth2 flow) where a user has to login before accessing a service. The login is handled by our OAuth provider and the entire flow results in 10 redirects before user is able to access the back-end service.
I have created users in OAuth Provider using Gatling “before” and I am running the scenario by randomly picking users using feeder.
The problem is that once the active user count reaches around 500 (even though the number of requests generated is almost same), a lot of requests (from the redirects) start failing. I am not able to figure out if its a problem with Gatling threads or the OAuth2 provider.

See the scenario I am running:
setUp(
userCredentialsV1StressTest.inject(
rampUsers(20) during (60 second),
constantUsersPerSec(15) during 1.minute
),
userCredentialsV2StressTest.inject(
rampUsers(20) during (60 seconds),
constantUsersPerSec(15) during 1.minute
)
)

The number of requests generated is approximately same, only active user count increased (see the attached screenshot), why does it behave this way ?

Thanks

500 users is very low number for gatling.
Lower if you have enough pauses between each request in your scenario.

You seem to have reach the point of gatling => load testing your server under a heavy load ^^

We have no pause between redirects.
What I don’t understand is why the increase in number of active users results in failures when the number of request sent to server is same throughout as you can see in the graph.

Oh, I didn’t understand that there was the same throughput.

In that case, there may be several possibilities:

  • you use throttle (but I don’t see it in your simulation) and there are more and more users that cannot send their requests (because of throttle)
  • you reached the limit of your own bandwidth or the bandwidth of your server, the requests are not limited, they timeout
  • you reached the limit of your server (physically), and it answered with a long delay… causing users to timeout after some redirects
  • you reached the limit of your server (feature), and it answered with some protection answers (error 429 too many requests)

Without more precision of your case, I think that it is server side.