How come this setting causes immediate rate limiting when ramping up concurrent bot sessions?
I am running a load test against the Architect Virtual Agent using JMeter 5.6.2. The goal is to simulate 500 concurrent users interacting with the bot simultaneously. The environment is Genesys Cloud (US1).
The test plan uses a Thread Group with 500 threads, ramp-up time 60 seconds. Each thread sends a POST request to /v2/conversations/bot. The payload includes standard conversation metadata. After approximately 200 active sessions, the API starts returning 429 status codes. The error response indicates RATE_LIMIT_EXCEEDED.
I have checked the API documentation. The standard limit for conversation creation is high, but the bot engine seems to have a lower threshold for concurrent session initialization. The error occurs before the bot logic even executes. It happens at the connection establishment phase.
Here is the JSON payload sent in the request body:
{
"routing": {
"queueId": "bot-queue-id-123",
"skill": {
"name": "general",
"level": 1
}
},
"to": {
"address": "[email protected]",
"type": "email"
},
"from": {
"address": "[email protected]",
"type": "bot"
},
"type": "chat",
"wrapUpCode": null
}
The JMeter configuration uses HTTP Request Defaults. The timeout is set to 30000 ms. Connection timeout is 10000 ms. I have added a constant throughput timer to limit requests per second, but the 429 errors persist.
Is there a specific configuration in the Virtual Agent settings that controls the max concurrent sessions? Or is this a hard limit on the tenant level? I need to know if I can adjust the maxConcurrentSessions parameter in the bot definition.
The logs show the error coming from the gateway, not the bot logic. This suggests the connection pool is exhausted. How do I scale the bot session capacity? I cannot find a setting for this in the admin console. Any guidance on the correct JMeter thread model for bot testing would be appreciated. I want to avoid hitting the rate limit wall.