Repository navigation
DPL Analysis: query the CCDB once per run of equal timestamps - #16080
Merged
Merged
Conversation
populateCacheWith created the pmr vector for the object, which matches the output route and looks up its transport, for every FetchOp. On a cache hit the vector is never used, and the analysis CCDB fetcher issues one FetchOp per column for every row of the source table. Create it only where an object is actually requested from the server.
When a CCDB table has no separate uniformity column, the analysis CCDB fetcher called populateCacheWith for every row of the source table, so about 19k times per timeframe for a BC-indexed table such as the ones of propagation-service-v2, even though consecutive BCs share the same millisecond timestamp. Reuse the previous responses whenever the lookup key, the uniformity value or else the timestamp, is the same as the one of the previous row. Since the key determines every FetchOp of the row, the responses and hence the output table are unchanged. For the LHC25b4a6 AO2D of Hyperloop test 799098 this is about 350 runs of equal (millisecond) BC times over 1.17M BCs in 61 DFs, instead of one query per BC.
Member
Author
|
Only touches analysis CCDB code, which is not yet in production. Works for the full system test. Merging. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
When a CCDB table has no separate uniformity column, the analysis CCDB
fetcher called populateCacheWith for every row of the source table, so
about 19k times per timeframe for a BC-indexed table such as the ones of
propagation-service-v2, even though consecutive BCs share the same
millisecond timestamp. Reuse the previous responses whenever the lookup
key, the uniformity value or else the timestamp, is the same as the one
of the previous row. Since the key determines every FetchOp of the row,
the responses and hence the output table are unchanged.
For the LHC25b4a6 AO2D of Hyperloop test 799098 this is about 350 runs of
equal (millisecond) BC times over 1.17M BCs in 61 DFs, instead of one
query per BC.