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.
original issue
I was originally writing issue on carbonapi github Issue
after some debug and code reading, i found out issue is with the carbonserver->render->cache function
the PR provided fix would expand cache key by 2 times, i dont like it, but i think you guys want to keep this key so its human readable?
the preferable way is run md5sum on
strings.Join(targetKeys, "&")
before line 318 so the key would be way less in length but it wont be human readablelet me describe the issue here again
when you generate two queries similarly with the same from&until in the same request
metrics.FRP[PPP]-ADE*-IAD[23].*_*.impression_log_DEBUG_FIELD_VPS_COUNT
metrics.FRP[PP]-ADE*-IAD[23].*_*.impression_log_DEBUG_FIELD_VPS_COUNT
curl would be like this
Both should return exactly same result (but in our test when cache enabled sometime it wouldnt)
and we have carbonapi->go-carbon through pbv3
the problem
so the problem is when you have carbonserver render cache enabled.
it would take the targets->
targets map[timeRange][]target
and generate a key based on names&from&untilso in my example, the first query would generate bunch of cache that has key->value which would be used (cache hit) in second query since they should be returning exactly same data (assuming they are not expired)
so when
First query caches the key, it stores the value of the key, which is
response
type which containsPathExpression
of first query'sPathExpression
then
Second query would hit some of the cache (First query sets), and it gets the
response
from cache with First querysPathExpression
,as a result
when this gets returned to carbonapi, carbonapi would treat it as wrong request target, the data would not be merged to second query's exprssion cause Second query has different
PathExpression
than Frist queryi added some debug code to carbonapi and generate this
wrong
right
as you can see some of the data gets the key as
{ 1661708059 1662414416}
because they contian first query'sPathExpression
due to cache hitif you would not care about key being too long, the PR is enough to fix the problem
but if you want shorter key, i can change md5 before key generation so it would just be a
md5sum + format
easy work around
an easy work around is turn off the render cache
btw i didnt really test the code, i just write it as my golang memory allow, i can add test case or if we wanna go other direction