-
Notifications
You must be signed in to change notification settings - Fork 491
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
CPU hotpath originating in CosmosQueryClientCore.GetCosmosElementResponse
#2815
Labels
Comments
@sourabh1007 what else is pending for this issue? |
This was
linked to
pull requests
Dec 24, 2021
It can be closed now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Seeing CPU hotpath that is originating in
CosmosQueryClientCore.GetCosmosElementResponse
which is using 6% of application CPU during a query workload.Flame graph reference internal link:
Zooming into the
QueryPage
ctor:The main issue is whether this CPU impact can be reduced when SDK is handling high volume query workloads.
Within this hotpath two methods are of note:
Page
ctor is creating anImmutableDictionary
forAdditionalHeaders
property, see -ImmutableDictionary
is known to be much slower thanDictionary
, so maybeIReadOnlyDictionary
would be better for this even if the trade-off is that true immutability guarantee is lost?QueryExceutionInfo header is deserialized with Newtonsoft.Json here - Would it be more performant to use the Json text readers built-in to the SDK instead?
To Reproduce
Run a high volume query workload and monitor/profile on the SDK.
More likely to see the issue with the following setup/workload
Expected behavior
Expect a lower CPU impact on an application for the critical path in query responses.
Actual behavior
Higher CPU impact for query response handling especially when very few items are returned.
Environment summary
SDK Version: 3.21/Any
OS Version: Win 10
The text was updated successfully, but these errors were encountered: