backend: Provide extensive statistics bounded to 1k #561
Conversation
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
| target_os: self.target_os.generate_ranking_top(10), | ||
| target_arch: self.target_arch.generate_ranking_top(10), | ||
| cpu: self.cpu.generate_ranking_top(10), | ||
| version: self.version.generate_ranking_top(MAXIMUM_STATS_COUNT), |
There was a problem hiding this comment.
Is it possible to add a few comments why 10 vs 1024 is used for certain metrics?
FYI, I have some troubles to understand the rationale behind by looking at the code, so I would like
to have either some kind of grouping by two different structs in ChainStats or add a few comments.
For example:
struct Chainstats {
// This contains full stats for the metrics
full_stats: FullStats
// This contains the top k stats for the metrics
top_k_stats: TopStats,
other: Other,
}
Thoughts?
There was a problem hiding this comment.
At the moment, staging does not propagate a meaningful number of statistics back to the frontend due to a limited variety of testing nodes with similar kernels and cpus.
I believe we'll end up taking a similar approach to this, but that decision still needs to be data-driven. In the meanwhile, will refactor the ChainStats to make it clear for which statistics we'd want more granular control in the frontend, good suggestion! Thanks!
|
@lexnv just looking through old PRs; what should we do about this one? :) |
|
I'll have another look over this PR, the general idea was to provide more data to the front end. |
The purpose of this PR is to test in staging that the frontend can handle the messages exposed by the backed; as well as finding a directional limit of: