-
-
Notifications
You must be signed in to change notification settings - Fork 179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: ability to track number of requests made #238
Comments
Good idea, I think we can shove it into ConsumedCapacity |
This is next on my to-do list, it will be helpful for testing once it's in. ETA this weekend. |
Sorry, got distracted by some other stuff ;) BTW, do you think it should count for every request "attempt" or every "successful request"? I'm thinking attempts. |
Awesome, thanks! I figure, in terms of retries, we might want to track semantic requests (i.e. a page of query results) vs low-level requests separately. iow, if you fetch 5 pages of results, but one of those pages needed to be tried twice, then it'd be useful to distinguish that there were 5 total pages, but 6 total requests. I could see that being distinguished by the addition of a Pages counter, which only tracks original outgoing requests (not retries), at which point Requests could get hooked into that SDK middleware. Alternatively, a Retries counter could be added, and would stay zero unless retries were made; at that point, to infer "Pages", it'd be |
Related to controlling pagination via #231, it would be useful to known how many top-level DynamoDB requests were made as part of a high-level operation. Typically this would be for queries/scans (how many sequential pages were fetched?), though potentially it could also apply to BatchWriteItem or BatchReadItem calls.
Perhaps this could live in
ConsumedCapacity
.It's unclear if there's value in distinguishing between planned-for requests and actual requests, in order to account for retries due to throttling, etc. Retries could also be tracked explicitly, of course.
The text was updated successfully, but these errors were encountered: