What’s the best way to handle screen recording retrieval when JMeter hits 500 concurrent users? The GET /api/v2/recordings/medias endpoint returns 500 Internal Server Error after 10 seconds, even with valid tokens. The WebSocket connection drops immediately following the failure. Thanks for the help.
If you check the docs, they mention that high-concurrency retrieval requests often trigger internal resource exhaustion on the media processing nodes, leading to 500 errors rather than standard rate-limit 429s. This is especially true when JMeter simulates 500 concurrent users hammering the GET /api/v2/recordings/medias endpoint. The platform is not designed for synchronous, high-volume media blob retrieval in this manner. Instead, the recommended pattern for AppFoundry integrations is to use the asynchronous export API or paginate requests with significant backoff.
For screen recordings specifically, the GET endpoint is strictly for metadata and small snippets, not full media streams under load. You should switch to the POST /api/v2/recordings/medias/export endpoint. This creates a background job that generates a signed URL for the media, which is far more resilient to concurrency.
Here is the corrected payload structure for initiating an asynchronous export:
{
"recordingIds": ["rec-123", "rec-124"],
"mediaType": "screen",
"format": "mp4",
"callbackUrl": "https://your-app.com/webhook/export-complete"
}
Additionally, ensure your JMeter script implements exponential backoff for any 429 responses before they escalate to 500s. The WebSocket drop is a symptom of the underlying HTTP failure, so fixing the retrieval method resolves the connection instability. Do not attempt to parallelize media downloads beyond 10-20 concurrent connections per org without explicit capacity planning approval from support. The platform’s media storage layer has strict I/O limits that are easily breached by synthetic load tests.