De retour ce lundi matin, je viens de faire un tag release, Gladys v4.7.3.
En cours de build ici :
@lmilcent Content que ça fixe tous tes problèmes de perf !! 
@VonOx ça a résolu les soucis que tu avais aussi ?
Oui le ressenti est mieux, je te redis dans quelques jours.
1 Like
Good evening,
I’d like to know how the dashboard is refreshed?
Is it cyclically or is it when a value changes state?
Thanks
Normally it’s live (when a state changes, it’s propagated to the front-end)
But there were oversights on certain boxes where that’s not done, we already have GitHub issues and @AlexTrovato made a PR on the subject 
Thanks @pierre-gilles
Because indeed, I have « Etat » MQTT functions that sometimes don’t refresh; I have to reload the dashboard page, but maybe I’m also not waiting long enough for the refresh to take effect on the dashboard, since the associated Telegram message does arrive.
Which box on the dashboard?
On a box " Room devices"
Ah, that’s not normal. Normally this box works perfectly.
Is the problem local or on Gladys Plus?
Hello @pierre-gilles
It’s local, I haven’t tested on G+
I don’t understand, I built a sensor with 2 functions on an ESP8266 that transmits via MQTT to Gladys
one of them reacts correctly, but the other, as I told you, does send the Telegram message when its state changes, but doesn’t update on the dashboard and when I refresh the web page (dashboard) the function’s display updates. I’ll dig deeper into the research, I’ll keep you posted
Sorry for the time you’ve wasted.
Hi,
I would like to check something with you (and @pierre-gilles).
When I load a dashboard, Gladys should fetch 100 values from the DB to display them afterward, right?
As far as I know, this shouldn’t generate a large disk (I/O) load. So I can’t explain the 100% I/O usage with a max at 19Mb/sec when I load a new dashboard.
Video proof:
Not exactly, it depends on the selected interval
Here when you request the last 24h, Gladys uses hourly aggregation (100 values per hour)
Over 24h, that means the DB retrieves 100 * 24 = 2400 states THEN adds a layer of downsampling on the CPU side to end up with 100 states sent in the API response.
On your chart, you display 6 charts * 2 features = 12 requests * 2400 = 28.8k states retrieved
So what you’re showing us doesn’t surprise me given the current state!
We could change how the « 24h » filter works to use daily aggregation (100 values/day), but we’d need to see how it looks — it may not be as clean as it is currently; we need to run tests
Edit: that wouldn’t work, see next post ( Dashboard - Evolutions / Bugs / etc - #134 par pierre-gilles )
Aaaaaaaaaaah I understand better !
I had thought it was 100x values over 1h, 24h, 7d, etc.
But no, actually the aggregation is limited to 24h, and then all the data is retrieved and computed on demand as you described.
So indeed, nothing unusual at all.
No, you (almost) had it right!
I quote the launch announcement:
- Hourly aggregation is calculated every hour (the previous hour is computed)
- Daily aggregation is calculated every day at midnight (the previous day is computed)
- Monthly aggregation is calculated every 1st of the month month at midnight (the previous month is computed)
But the thing is, when you display the « last 24h » view, imagine you display that view at 6pm, the daily aggregation for the current day is not ready yet (it will be calculated at midnight), so we use the hourly aggregation which is available.
In my tests, I tried to make a mix by doing:
If you request the dashboard view at 6pm:
- Take from 6pm to midnight of the previous day via the daily aggregation
- Take from 00:00 to 5pm using the hourly aggregation
- Take from 5pm to 6pm by taking the live data
But it really doesn’t look good, the mixed data makes the « jumps » clearly visible on the chart; it’s really not clean.
1 Like
Thank you for the description, explained like that it’s perfectly logical.
In the end I edited my dashboards to display only the last hour by default. Then, when needed, I load the last 24 hours.
This allows me to maintain real responsiveness and avoid overloading Gladys for 10 to 20 seconds.
Otherwise you should invest, @lmilcent
Joking aside, a Pi might be a bit underpowered for you, no?
I’m telling you this because I tested it
3 Likes
Too noisy sorry
I managed to get a mini PC with an SSD, so yes clearly it will be muuuuch more powerful. I installed it but I haven’t yet taken (had) the time to do the Gladys migration.
When that’s done I’ll give you my feedback on the difference in latency in particular — it will probably be pretty obvious in my case!
After that I’ll just need to repurpose my RPis as RTSP cameras for example
1 Like
There it’s clearly the disk that’s the limiting factor for you, are you on a micro SD card or an SSD, I don’t remember?
At 20 MB/s it’s clearly neither an HDD nor an SSD
It’s indeed a basic Raspberry Pi 4 for now.
1 Like