Skip to content

Advanced metrics visualization#6602

Draft
Karakatiza666 wants to merge 1 commit into
mainfrom
advanced-metrics
Draft

Advanced metrics visualization#6602
Karakatiza666 wants to merge 1 commit into
mainfrom
advanced-metrics

Conversation

@Karakatiza666

Copy link
Copy Markdown
Contributor

This PR introduces multiple new widgets for visualizing the profile metrics. The goal is to to try to effectively summarize the relationships between the metrics to convert a wall of numbers into distinct charts that allow to see relationships and trends without reading through every number, while still allowing to inspect individual values when necessary.

Every widget is designed to accommodate a large number of workers without complicating or visually cluttering the visualization.

The charts may seem involved, but I feel they are very information dense and yet easy to read after getting used to them.

Once I confirm the direction I will ask Anna for feedback on the design. I needed to come up with ways to summarize necessary relationships in a compact footprint.

The widgets in this PR:

  • Percentage widget - clearly visualizes percentage for many workers in a compact widget
image =========================================
  • Composite cache widget - see how workers cluster in terms of cache latency, cache miss performance hit, etc.:
image =========================================
  • Input/output batches stats - see average records per batch and compare values workers
image =========================================
  • Compaction state matrix
image =========================================
  • Completed merges
image =========================================

Demo (ignore the mouse pointer - it glitched, frozen in place):
Screencast from 2026-07-08 18-59-19.webm

Please let me know if you would like to see a specific chart or relationship - we are using a powerful diagram library which enables most chart designs you can think of: https://echarts.apache.org/examples/en/index.html

Signed-off-by: Karakatiza666 <bulakh.96@gmail.com>

@mythical-fred mythical-fred left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Draft, so architecture-level notes only.

The generalisation from MetricsDistributionBlock to dispatch.ts + MetricKindBlock + per-kind primitives (BarChartRow, PercentBars, KeyDistributionMatrix, CompactionStateMetric, MergesHistogram, OccupancyRingMetric, EChart) is the right direction — a wall of if kind === K1 ... else if kind === K7 today, a table lookup tomorrow, easier to extend to K10+ without touching the block itself. Good separation.

Genuinely appreciated: unit tests. dispatch.test.ts, kind.test.ts, cache.test.ts, colors.test.ts are exactly the kind of coverage web-console has been missing for years. Please keep this reflex on every subsequent change; do not let it be a one-off.

Design questions worth resolving before marking ready:

  1. EChart.svelte is the escape hatch for a full charting library. Once several tiles adopt it (CompactionStateMetric, MergesHistogram, KeyDistributionMatrix, the cache scatter) the "one echarts instance per tile, per worker" pattern has to answer: bundle size, initial paint time on a 32-worker pipeline, teardown on route change. A single-page profiler with 5×6 tiles × 32 workers × echarts option object is not free. Confirm you have measured this and consider a shared registry / lazy import.

  2. any still appears in EChart.svelte, CacheCountsMetric, PercentBars, KeyDistributionMatrix, MergesHistogram (onclick, formatter, instance). For a PR that is otherwise raising the quality bar of this package, this is worth cleaning up before ready — echarts publishes proper types (ECElementEvent, CallbackDataParams, ECharts). any on chart callbacks defeats the point of the strict-mode work we have been pushing for.

  3. kindHelp.ts currently covers K6/K7/K9 only. Are the help entries for K1/K2 intentionally deferred, or is the help icon simply absent on those tiles? If the plan is "some kinds get help, others don't", document that in the README so nobody spends a day wondering why the icon is missing.

  4. README.md under metrics/ — nice touch. Extend it with the "how to add a new kind" recipe (dispatch entry, block type, part component, test file) so the next contributor doesn't have to reverse-engineer the taxonomy.

Once out of draft I will pull the whole profiler-layout/src/lib/components/metrics/** tree line-by-line; skipping detail feedback until then per draft policy.

@mihaibudiu

Copy link
Copy Markdown
Contributor

This should be broken down into multiple PRs, one per chart type.

@gz

gz commented Jul 9, 2026

Copy link
Copy Markdown
Contributor

Let's not invent new forms of graphs. if you want to visualize distributions you can use violin plots (preferable), box plots, scatterplots. And for the rest stick to standard plots too: lines, barcharts, pie charts, heatmaps etc..

No one has the time to learn and understand your fancy new plotting scheme for something like this. I can't understand what's going on looking at it for more than 3minutes and I spent most of my career looking at plots of computer systems.

@lalithsuresh

Copy link
Copy Markdown
Contributor

I echo @gz's input here. This is simply not effective and doesn't warrant inventing a new type of plot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants