Is there any ongoing work to make HABPanel a bit more performant?
I’ve got a nice display. But it has serious performance problems. Doesn’t matter whether I run it in Chrome or Safari, it usually chews about 30% of a core (i7 @ 2.3GHz - MacBook Pro late 2013). Not only is it slow, it has a nasty nasty habit of pausing and not doing anything for large periods of time. Including throwing up a red warning in the bottom RHC that the backend is ‘down’ or not responding…
It’s like it’s single threaded and requesting updates in the foreground…
RasPi-2 for the openHAB2 controller. And yeah, a few errors in the logs, but nothing that can be tied to the performance of the web interface.
Almost all the performance issue seems to be the javascript. There are truckloads of errors there. From getCurrentPosition() and watchPosition() trying to be used on an insecure connection (openhab landing page) to 'Cannot read property ‘LiveUpdates()’ of undefined
One thing that does popup a lot is 1 widget that seems to be trying to read the cpu load… Not sure why because I’m not graphing that… (I do have memory being graphed). It’s trying to load that every half second or so… That might be a smoking gun…
Can anyone tell me where the server saved config files live for HABpanel?
It looks like items that used to be in widgets on the page (e.g. CPU load) are still there even though they shouldn’t be a part of any current widgets… And they’re being polled at 0.5 - 1.0 sec intervals which is presumably one of the main causes of my performance issues.
If I can find the file I can manually edit it… Unless there’s a hidden option somewhere to doit in the HABpanel interface?
There’s also this… Looking at HABpanel with Safari developer tools, there a document being accessed called ‘events’ that the browser seems to spend all its time accessing…
You have an item that updates this often. HABPanel is watching for those changes in the EventSource, and logs every change to console before parsing it.
It’s not trying to load. It’s working as expected. It reacts to the changes published by the event source. Your item is changing that often, so habPanel reacts that often also.
Here’s a quick test. Open a new browser window, point it to http://YOUROH:PORT/rest/events
Watch how often your item state changes. This would be just as often HabPanel will parse them accordingly.
Jersey is not ready yet is expected. Habpanel resources (html/css/js/etc) are cached and also uses service workers, which means HABPanel will RUN even in offline mode even when server is not yet ready.
Read my comment about the event source above. It does not matter if the item is configured in HABPanel or not. If you have an item, it will be published through the event source, and publishing those changes are done my OH itself, not HABPanel.
Because that’s how it works. Without the event source, how would HABPanel know anything about your item state changes. Instead of using websockets, HABPanel is using EventSource . It’s a REST call but the connection is kept alive so clients can remain and “subscribe” to those events.
FYI… Im running one HABPanel instance on a chromium browser on a tiny orange pi zero h2 with only 512 RAM, 1.2ghz CPU and I have zero issues with performance.
A dumb question here . . . a 2 word response will suffice.
I run my OH on a raspberry pi 3.
I have a fairly large number of items / rules etc .
If I were to run my OH installation off of a more powerful platform (e.g. I have an old i5 desktop lying at home doing nothing) would the response times in HabPanel be noticably quicker, or will render times still be slow?
At the moment, a page change to a different panel on my MacBook takes a couple of seconds.
The same page change on a wall mount panel (4 year Galaxy Tab) can take 4 or 5 seconds.
I am just trying to figure out whether is worth the effort replacing my OH hardware.
happanel is mainly javascript driven which your browser downloads then runs. This is why you see the performance difference between your mac and tablet.
A more powerful OH server will maybe improve download time but the running and rendering of the pages is dependent on the hardware the browser is running in.
Thanks - I thought this might be the case.
I suspect I’ll potentially see updates to items in OH a little quicker, since some rules may process a little quicker (especially when I have multiple concurrent rules fire off.
I realise that some of my processes on the OH server are inefficient (e.g. I poll the Spotify Web API manually every 10 seconds, I update 4 image items from webcams every few seconds . . each consuming resources and so on)
Irrespective, that was a useful response.
A couple of further questions I have though.
When HabPanel renders a page, I am guessing it gathers ALL item states from the API (irrespective of whether it uses them) - so if I have 1000 items, all 1000 states are ripped as one json packet?
Do tabs, other than the one I am loading, cause any rendering, or is rendering limited to widgets on the current tab only?
If by tabs you mean dashboards, no only the visible widgets are rendered.
To debug performance problems, open the developer tools in Chrome, go to the Network tab and refresh the page. Check the Waterfall column.
If there’s a request, for instance “items”, taking a long time to complete (i.e. a long bar, disregard “events” because it’s a long-running SSE connection as explained above), that might be the cause of your dashboard taking a long time to appear.
That’s definitely too long - what are you running the openHAB server on? I’ve encountered slowdowns like this, and this was caused by something in openHAB (don’t know exactly what, might be the UPnP discovery service) hogging my RPi CPU to 100% and slowing down everything. Even with a few hundred items and half a dozen panel configurations, these requests should take well under 1 second on a RPi, check the CPU utilization and restart openHAB or reboot if necessary.
I still have performance issues with my install… Both chrome and safari tell me continually that the page is consuming too many resources… Look at the Javascript console and I see
Lots of updates for the CPU load state… Anyone know how to throttle that? Especially since I’m not graphing the Cpu load state (But am graphing the memory consumed… But that’s a 2W graph so the updates would seem to be a tad fast)
I have similair issue’s. Not sure what component of habpanel is causing the trouble. I don’t experience this when using basicui or paperui and as far as i know it uses the same rest api. Maybe you could change some update interval setting in the systeminfo binding, not sure if that is supported.
@vzorglub Vincent that’s also what I experience, HabPanel works fluently on my iPad Pro and Ipad mini4 but the iPad mini2 used as wall mount is really struggling. So it does require a powerfull end device
