Please do. Let me know if you want me to upgrade so you could look at before and after.
Still experiencing those spikes as you can see, and the latency between the spikes isn't that great. Hoping that next release improves. As far as my automation's they are working well enough, but there is still some delay that was not present before the 2.2.3 versions.
Did 2.2.3.142 update make a difference? How does the chart look?
Mine restarts daily at 0300, so probably too soon to tell. With that in mind, it looks very good so far.
2 Likes
As you can tell it did drop after the update yesterday, but I still see those spikes happening. It does look like the latency may be creeping up slowly, but its still too early to tell.
2 Likes
Here's what my three hubs look like before and after upgrading to 2.2.3.142. Notice the significant change (from ~0.5s to over 1s) in the baseline responsiveness of the C-3 hub (green trace). Prior to this upgrade, the C-3 and C-4 hubs were both running 2.2.3.136.
You probably answered this elsewhere already, but what page load times are you measuring with those graphs?
The http://hupIP/installedapp/list page. This is via Node-RED, to InfluxDB, to Grafana. It measures the page load time every 5 minutes.
2 Likes
Thanks, added to my list as well to collect and graph!
1 Like
The C-3 trace is interesting; even the C-7's baseline appears slightly elevated. I wonder if doing a soft reset would make a difference?
Reason for suggesting this: I noticed on initial update to .118 that my C-3 hub's min delays (virt. switch delay via Hub Watchdog) never went below .05; typically they run as low as .036 - .038 after a restart. Coincidentally, within a few hours of updating to 2.2.3.118 I noticed a failed simple Simple Lighting automation; normally I never see issues until the typical 3 days of excellent performance (at which point slowdowns and other bad behaviors begin). So I did a soft reset; I was surprised to see that min delays went down significantly (.031; some as low as .028).
After that, hub ran fine on .118 with no failures. Made it 5 days (with no noticeable issues) before observed min delays increased to .067 , though each day the min baseline seemed to creep up a bit. Nightly maintenance would shave it down somewhat, but never quite as low as after a restart.
I updated my C-3 to .142 this morning. Superstition made me do a soft reset immediately afterwards.
So far it has been quite fast; the .027 min delay is the fastest I've seen (single hub setup with most automations on WebCoRE). I haven't yet observed the 5 second spikes that have been typical of recent firmwares, but it has only been running for six hours.
meanD : 0.049
medianD : 0.033
minimumD : 0.027
1 Like
Thanks for the feedback. I have seen soft resets help to reset the baseline on previous platform updates over the past year or so. So, I will definitely give it a try when an opportunity presents itself.
1 Like
My hubs vary greatly with installed apps so I felt like this was not an apples to apples comparison. I changed mine to the system events page instead.
1 Like
Another update. All is still looking great. BTW, Hub 1 has Echo Speaks, Alexa, and HubConnect Server with 2 Homebridge instances and the 2nd HE instance as well as 70+ zigbee devices and 20 or so z-wave devices. 223 total devices with mirrored and virtual included.
3 Likes
C-7 hub with version 2.2.3.142. Ever since the .142 upgrade my hub and system have been running great! No slow downs or missed events. Thanks HE staff for your hard work on this.
5 Likes
Hub is still fast. I made some changes today and shut down and restarted the hub. The funny thing is, the hub seems to be slowest after a reboot or shutdown and restart. Granted, it’s still faster than it was with any previous firmware. It doesn’t seem to reach its peak until the next day.
My guess is, like any other OS, system processes are still loading after boot up. Those processes take priority. So less resources are given to other functions on the hub.
That's a keen observation! The same JVM flags that steer Java towards compiling (rather than interpreting) bytecode early and keeping it around for longer also mean that some time is spent compiling rather than running code early on. The payoff comes later.
3 Likes
I have found that the first time a device is used after a reboot it seems slow then ok after that.
No science behind it. Just a feeling.
