I have a JMeter setup that generates an access token which is passed to a subsequent thread group in the HTTP Header Manager. The Test Plan looks like this:
ThreadGroup (here is where the bearer token is generated)
-HTTP Request
-JSON Extractor
-BeanShell Assertion (here I am using the __setProperty() function to be able to use the token across different threadGroups)
ThreadGroup2 (actual test)
-HTTP Request
--HTTP Header Manager (the authentication token is passed here)
The problem: the above setup works fine functional wise, however, the problem occurs when I try to add more users to ThreadGroup2. Concretely, if I run the test with 100 users, it works perfectly fine. If I increase the number of users to 150, then all requests fail with 403 Forbidden, as if the access token is no longer passed in the HTTP Header Manager of the request. I assumed that the test is running too fast for JMeter to be able to compute everything (e.g. to pass the access token via the __setProperty() function), so I tried hard-coding the access token in the HTTP Header Manager of ThreadGroup2 but the issue is still the same. I am unable to understand the reason for this, can it be application-sided (e.g. the application cannot handle the load hence the failures, but if this is the case, why 403 Forbidden?). Or is there a way I can understand why this is happening and maybe fix it?
First of all I would recommend checking what exactly is going on by temporarily enabling storing request and response data. It can be done by:
either amending JMeter Properties responsible for Results file configuration, this way requests and responses details will be written to the .jtl results file
or adding a Listener like Simple Data Writer and you will be able to choose what and where to store
More information: How to Save Response Data in JMeter
If you think that JMeter is causing the problem make sure you're following JMeter Best Practices, you're violating at least one of them as using Beanshell is not recommended
Check your application configuration and logs. If you're using a single authorization token for 100+ threads it might be the case the application doesn't allow this. Also it could be the case of rate limiting. My expectation is that you should be using a separate token per thread (virtual user) rather than re-using a single token with 100+ threads
Your application might be overloaded and simply cannot support that many users. In this case you need to identify the reason of the bottleneck and either report or fix it.