Skip to content
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

Open
extemporalgenome opened this issue Jun 21, 2024 · 5 comments
Open

Feature request: ability to track number of requests made #238

extemporalgenome opened this issue Jun 21, 2024 · 5 comments

Comments

@extemporalgenome
Copy link

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.

@guregu
Copy link
Owner

guregu commented Jun 24, 2024

Good idea, I think we can shove it into ConsumedCapacity

@guregu
Copy link
Owner

guregu commented Jul 3, 2024

This is next on my to-do list, it will be helpful for testing once it's in. ETA this weekend.

@guregu
Copy link
Owner

guregu commented Jul 15, 2024

Sorry, got distracted by some other stuff ;)
Still at the top of the TODO list

BTW, do you think it should count for every request "attempt" or every "successful request"? I'm thinking attempts.
Example: query -> throttled -> retry query = 2 requests

@guregu guregu mentioned this issue Jul 16, 2024
@guregu
Copy link
Owner

guregu commented Jul 16, 2024

Just released v2.1.0 which includes a Requests field in ConsumedCapacity. It's not perfect (see #241) but it will get you most of the way there.

@extemporalgenome
Copy link
Author

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 Requests - Retries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants