-
Notifications
You must be signed in to change notification settings - Fork 5.5k
decompressor library: add stats to zlib library #11782
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
Changes from 8 commits
5b4033e
15baceb
98c7fba
bd36392
fbf4bc2
e74988f
62ff4b8
4d26676
da5338a
3558b96
b9f7925
3461fca
02c34fd
bc382b0
6c07141
cf0f748
4ce4063
6e9e0a3
b7e7458
d2b753f
469e75f
3e7be62
e06a96e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -94,7 +94,7 @@ class DecompressorFilterConfig { | |
| Compression::Decompressor::DecompressorFactoryPtr decompressor_factory); | ||
|
|
||
| Compression::Decompressor::DecompressorPtr makeDecompressor() { | ||
| return decompressor_factory_->createDecompressor(); | ||
| return decompressor_factory_->createDecompressor(stats_prefix_ + "decompressor_library"); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we make this stat prefix be a part of
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I debated this back and forth because I am not sure if we would have a place where we would want each decompressor created by the same factory to have different strings.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. lets just do it the way you suggest. Having the string concatenation in the hot path seems like a bad price to pay for the niche ability to configure stats trees differently for individual decompressors.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nvm all of the above. I now do understand what you mean. Let me know if what I have pushed is not it.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's definitely better. Though I was thinking about changing the meaning of Then
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I didn’t want to do that because I don’t want the filter stats to have the decompressor_library prefix. To me the public statsPrefix function is for a consumer to use. And the argument in createDeconoressor is what the consumer wants to ultimately root the decompressor at.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Alright, fair enough. |
||
| } | ||
| const std::string& contentEncoding() { return decompressor_factory_->contentEncoding(); } | ||
| const RequestDirectionConfig& requestDirectionConfig() { return request_direction_config_; } | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it enough for your use case not to differentiate errors by their type?
I'm thinking that it might be useful to check the stats and see what's wrong immediately (e.g. is it
Z_DATA_ERRORorZ_MEM_ERROR?) instead of increasing log verbosity totrace.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue is that even a
Z_DATA_ERRORcan have dozens of different reasons for occurring, so you would still need to look at logs to get at the heart of it. However, I do think your idea of differentiating based on returned error code is good. I'll make the change.