Textract timeframes used for calculation of quota / request rate limit exceeded

Question

Hello,
We are running a service in region eu-west-1 with a synchronous operations quota of 5RPS. We use synchronous operation: https://docs.aws.amazon.com/textract/latest/dg/API_AnalyzeDocument.html with boto3.
What we observe during load testing of our service for the testcase when textract is involved, somewhere between 3-5 RPS we start hitting already in few and then more cases this quota rate limit.
So, overall per second less than 5RPS. But probably not distributed evenly over the second.
For us it seems like a similar behavior what you can find in nginx or other loadbalancers, reverse proxies, rate gate libs etc. So 5RPS could be reflected on some other time frame calculation, like 5RPS = 1 request max for each 200ms or some throttling after the first 100ms of a second.

We would like to know what mechanism we can expect here as retries are expensive performance wise and might make the situation worse and even doubling the quota from 5RPS to 10RPS or more might not resolve this problem, as doing the math down to smaller time frames it is just 2 requests instead of 1, while we might stay far below 10 request for the whole second.

re:Post Agent · Answer

Hello,

Thank you for your detailed question about Amazon Textract's rate limiting behavior. Let me provide a comprehensive response based on AWS Textract documentation [1].

You're experiencing throttling at 3-5 RPS with a 5 RPS quota in eu-west-1 for synchronous AnalyzeDocument operations, suggesting uneven request distribution issues.

1. Understanding the Throttling Behavior:
When you exceed the TPS limits, Amazon Textract will throttle your requests and send a ProvisionedThroughputExceededException error. This can happen even when you're technically below the stated 5 RPS limit due to uneven request distribution [2].

2. Recommended Solutions:

a) Implement Traffic Smoothing:
- Use a queueing server-less architecture to "smooth" your traffic patterns [2]
- This helps maintain consistent throughput for your allotted TPS
- Reduces spiky traffic that can trigger throttling

b) Configure Proper Retry Handling:
- Implement exponential backoff and jitter in your retry logic
- Set up the AWS SDK with Config parameter for retries [2]:
```python
config = Config(retries = dict(max_attempts = 5))
textract = boto3.client('textract', config=config)
```

c) Evaluate Your Quota Needs: [3]
- Access the Textract Service Quotas Calculator in your console to:
  * Calculate optimal quota values based on your daily document volume
  * Determine if current throttling issues are quota-related
  * Plan appropriate quota increases through Service Quotas console

3. Alternative Approaches:
- Consider asynchronous operations for high-volume processing [4]
- Async operations support up to 600 concurrent jobs [5]
- Better suited for large-scale document processing

4. Implementation Best Practices:
- Reference AWS-provided IDP CDK Samples for implementation guidance
- Monitor your application's performance
- Implement proper error handling for throttling scenarios

The key to resolving your issue lies in implementing proper traffic smoothing and request handling rather than focusing solely on quota increases. These recommendations should help optimise your Textract implementation while maintaining reliable performance.

References:
[1] https://docs.aws.amazon.com/textract/latest/dg/sync.html 
[2] https://docs.aws.amazon.com/textract/latest/dg/handling-errors.html 
[3] https://docs.aws.amazon.com/textract/latest/dg/limits-quotas-explained.html 
[4] https://docs.aws.amazon.com/textract/latest/dg/handling-errors.html 
[5] https://docs.aws.amazon.com/textract/latest/dg/limits-quotas-explained.html 
[6] https://docs.aws.amazon.com/textract/latest/dg/async.html

Textract timeframes used for calculation of quota / request rate limit exceeded

Relevant content