Quick question about OAuth token refresh rate limits during load testing

Administration
1

Quick question about handling OAuth token expiration when simulating high-concurrency API traffic from Singapore.

I am running a JMeter 5.6.2 script to test the throughput of the /api/v2/architect/flows endpoint. The goal is to simulate 500 concurrent users fetching flow configurations. Everything works fine for the first 100 requests, but then I start seeing intermittent 401 Unauthorized errors.

I have a JSR223 PreProcessor in JMeter that checks the token expiry and calls /oauth/token to refresh it if needed. However, under load, multiple threads seem to trigger the refresh simultaneously, resulting in a rate limit 429 on the auth endpoint itself. This causes the main test threads to hang waiting for a valid token, skewing the latency metrics completely.

The environment is Genesys Cloud (US-East). I am using a dedicated test tenant for this. The JMeter config uses a simple controller with a loop count of 100 per thread group.

Is there a recommended pattern for managing token refresh in a high-concurrency load test? Should I be using a singleton token manager in JMeter, or is there a specific header or parameter I can use to batch the refresh requests?

Currently, my script looks like this:

  • Thread Group: 500 threads, ramp-up 60 seconds
  • HTTP Request Defaults: Base URL https://api.mypurecloud.com
  • PreProcessor: Checks exp claim in JWT. If exp < now + 60s, calls /oauth/token with grant_type=refresh_token.

The issue is that when 50 threads check the token at the same millisecond, they all decide it’s expired and hit the auth server. This creates a thundering herd problem on the /oauth/token endpoint.

Any advice on how to structure this in JMeter to avoid hitting the auth rate limits while maintaining accurate concurrency simulation? I want to ensure the load test reflects real-world API throughput without being bottlenecked by auth mechanics.