Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add a request time metric to redis upstream #7890
Add a request time metric to redis upstream #7890
Changes from 33 commits
e6731a9
35b6128
028924c
bad7ea4
a1288f1
44cc44d
723a8fd
2c169e2
8b05c9b
e74161a
8336e68
359679e
506e724
054400b
e5770f1
a110c26
4f72856
7af7c7c
e06eb57
04314f5
3e8636e
6c5a8ca
89c1b26
b4e5944
ab8047b
2441b00
90afb6f
94c0a7e
c945058
54b168f
0f93e03
7f0001c
d04ef29
4a028ae
b25b4d2
becaba2
f6ec8bf
703d0fe
fe218a7
7f70392
66cb5fd
3ce76bf
7877ee7
6d7c4b5
8d9d3d1
bc5a96f
4e82245
abf2297
841b4a3
2520b40
f76c164
140d9e5
414e5b3
9ec13ee
4ad0e2c
228af54
f2b036f
d578a4b
6904da0
4fe9265
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I think we want to hold RedisCommandStats in your Config, not in ClientImpl. It will be expensive to create, basically read-only, and there could be more than one Redis client in a process.
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.
I will give this a try tmw.
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.
hmmm....should we do the lower-casing inside getCommandFromRequest? Or is it useful in some contexts to have non-lower-cased names?
I think from reading this PR that you don't use the command name at all unless stats are enabled. Is that right? In that case I think we should skip the lower-casing and string-copying if enableCommandsStats() is false.
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.
Ok, in my update to the PR, I've added an "unused" statname, and used that for this ie
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.
Consider using your StatNameSet to store command_ as a StatName only. Then when you pass them around you don't need to do a bunch of string-copies, and it will enable you to compose all the stat-names strictly from other stat-names via SymbolTable::join(), which should be faster and lock-free.
If you know the most likely set of Redis commands you can remember them as builtins in your StatNameSet at construction time, and never thereafter have to take locks to get StatNames from known commands.
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.
Per my other comment on how commands are extracted from Redis
RespValue
, I don't think we have a great way to do this. We'll always need to map a string command to aStatName
.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.
Yes we will need one map lookup for the command since it is received in the wire as a string.
But ideally you should have a finite set of known commands that you can register as built-ins at construction time so that the StatNameSet can finish the lookup in its built-in map, which doesn't require a lock.
If you receive an unexpected command then the StatNameSet will fall back to taking a lock and doing the lookup in its dynamic map, which then falls back to the global symbol table.
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.
My suggestion stands. Store this in the structure as
Stats::StatName command_;
and change call-sites to match. I'll mark up the other lines of code that have to change for this to work.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.
Ok, I've updated this and will push update here shortly.