Post B9NKXYfPx3hMye0pwe by cks@mastodon.social
(DIR) More posts by cks@mastodon.social
(DIR) Post #B9NHUhYq809bpVskZk by wolf480pl@mstdn.io
0 likes, 0 repeats
@cks yeah, and it makes it so that when you have 20 tabs of grafana open (as one does) your computer starts getting slow
(DIR) Post #B9NHdMAd1ira5vgUtM by wolf480pl@mstdn.io
0 likes, 0 repeats
@cks like, don't get me wrong, the chart navigation (zooming, filtering) and editing UI of Grafana is amazingBut I also find it incredible that there is no real alternative.Like come on, Grafana has existed for 10 years, we can do better than that
(DIR) Post #B9NI2rAysxY1Ur0bRI by cks@mastodon.social
0 likes, 0 repeats
@wolf480pl It's a lot of work to build something Grafana-like. People are actually trying because of the various actions of Grafana the company¹, but it's clearly not going very fast. I hope they'll get there someday since I no longer trust the company, but.¹ eg https://github.com/perses/perses (there's https://github.com/credativ/plutono but it's not trying to be an alternative in a strong sense).
(DIR) Post #B9NIKHGJ9TWfK7o6gS by wolf480pl@mstdn.io
0 likes, 0 repeats
@cks tbh I'd prefer something with no builtin editor, that just consumes dashboards as code, does some pre-processing, and spits out a website that can display 100+ real-time graphs on an average computerBuuut I don't know enough about web performance to even know if something like that is possible :/
(DIR) Post #B9NJ0v7BN1FF5Ts9XU by cks@mastodon.social
0 likes, 0 repeats
@wolf480pl I think it's hard to do substantially better than Grafana in terms of load. You have to render the graphs client-side in order to enable various features (eg, turning on and off specific lines on a graph), so you're pushing data points to clients, and if you want real-time updates that has to be done outside the initial HTML, and etc.
(DIR) Post #B9NJEG5gh4RDuKX8We by wolf480pl@mstdn.io
0 likes, 0 repeats
@cks yeah, it doesn't seem like something the browser can help you with, so you'd probably have to reach straight for canvas and/or WebGL, and write it like a fullscreen game, except with browser overhead...
(DIR) Post #B9NJacOOSOwDRhwe6i by cks@mastodon.social
0 likes, 0 repeats
@wolf480pl I believe canvas elements are pretty much how Grafana does all its graphs, although I haven't actually looked at the DOM. Maybe you could turn the points and etc into SVGs on the fly or something.
(DIR) Post #B9NKG0cdHD04SwLFYG by wolf480pl@mstdn.io
0 likes, 0 repeats
@cks I doubt it'd be fast... but also, AFAIK grafana frontend fetches the dashboard definition as json from the backend, and interprets it... imagine all the dynamic branches this takesI guess a good JS JIT can get rid of most of them, but I still wonder if compiling a specific dashboard to wasm would make things faster
(DIR) Post #B9NKXYfPx3hMye0pwe by cks@mastodon.social
0 likes, 0 repeats
@wolf480pl My wild-ass guess is that the cost of materializing the definition from JSON is paid only in the initial setup, where presumably it builds a HTML DOM and populates it with all the data and hooks. From there I'd guess that updates are about as efficient as you'd get from materializing the HTML on the server and sending it.(Grafana does have further inefficiencies, like issuing queries from the browser through the server. But I suspect they're not *major*.)
(DIR) Post #B9NKjPxEAffXQizwFU by wolf480pl@mstdn.io
0 likes, 0 repeats
@cks yeah the point is to not have DOM (maybe except for the navbar).one canvasone websocket with samples flowing in in a binary formatone wasm binary that turns samples and mouse events into pixels
(DIR) Post #B9NKxMlQpTCXad8ESG by cks@mastodon.social
0 likes, 0 repeats
@wolf480pl I think that would be pretty challenging. The browser's HTML DOM rendering is doing a lot of heavy lifting for Grafana dashboards in the face of things like variable sized browser windows and resizing the browser. If WASM takes all of that over, it's all on WASM; you're basically running a display server plus an app in WASM. I'm not convinced this would have better performance than HTML DOM + JS that's mostly sitting there outside of updates.
(DIR) Post #B9NLP6KdW7lGjbp7U8 by wolf480pl@mstdn.io
0 likes, 0 repeats
@cks yeah, there'd be tradeoffs....probably stick to one bad font, ASCII only
(DIR) Post #B9NLRWMFiwBK23jWpU by wolf480pl@mstdn.io
0 likes, 0 repeats
@cks make it look like MS-DOS, then people won't complain about the font
(DIR) Post #B9NLc1vBE7vuou579U by wolf480pl@mstdn.io
0 likes, 0 repeats
@cks you just reminded me that not knowing why it's difficult is a prerequisite of doing something difficult
(DIR) Post #B9NSQpM8IrnaLLIGwK by cks@mastodon.social
0 likes, 0 repeats
@wolf480pl I do wish there was a Grafana-like thing where I could write out my dashboards in some sort of plain text (Grafana's JSON provisioning is lol). And who knows, I could be wrong about the WASM stuff, I've been massively wrong in the past.(It certainly would be nifty to take all of the statically defined calculations and merging and sorting for each panel and pre-compile them to a WASM thing, that is possibly expensive.)
(DIR) Post #B9NSgJPArce9sm6Fxg by wolf480pl@mstdn.io
0 likes, 0 repeats
@cks tbh if I was to try something like that, what I'd do first is an sdl (or maybe pure wayland) native application that reads samples from stdin and renders one hardcoded graph, with axes, as fast as possiblethen try to port that into browser+wasm+canvas and see if it gets much slowerthen become convinced a faster grafana is possible and drop the project :P
(DIR) Post #B9NSnK8CYuXWA6VLOq by wolf480pl@mstdn.io
0 likes, 0 repeats
@cks but yeah, a good declarative language for describing dashboards, even if they get compiled to grafana (or perses) JSON would be quite nice