Performance

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.

1 Like

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.

Thanks

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.

  1. 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?

  2. Do tabs, other than the one I am loading, cause any rendering, or is rendering limited to widgets on the current tab only?

Thanks

I don’t know the answers to these questions. This is the internal workings of habpanel.

@ysc
Do you have the answers to these two questions, please?

Correct.

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.

2 Likes

Thank you @ysc Yannick, alway very clear and concise.
Very helpful hints about chrome dev tools

1 Like

Thanks very much Yannick, very helpful - and super work!

found http://192.168.0.131:8080/rest/services/org.openhab.habpanel/config download was pulling all my old panels for various devices, rather than just the current habpanel design - was taking over 2 seconds (removed a few and immediate improvement)

Also noticed that my items download takes over 1.5 seconds, so will try clean that up.

What I can’t work out though is why there is a delay between:
http://192.168.0.131:8080/habpanel/app/settings/settings.widgets.designer.controller.js
and the START of
http://192.168.0.131:8080/rest/services/org.eclipse.smarthome.core.i18nprovider/config

and then another long one between:
http://192.168.0.131:8080/habpanel/vendor/i18n/angular-locale_en-gb.js
and
http://192.168.0.131:8080/habpanel/fonts/roboto/Roboto-Regular.woff2

The delay amounts to over a second each time?

The latter of the 2 above though may well be waiting for completion of:
http://192.168.0.131:8080/rest/services/org.openhab.habpanel/config

Finally, I scrape a web url as a ‘lazy’ widget - is there a way to force processing of that component to the very end of my load queue?

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.

Afraid not.

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

Thanks for that,
Any recommendations for cheap tabs that are powerful enough to run smoothly??

Just an idea but is it correct that habpanel receives updates on all items that are present in the OpenHAB installation?
When I looked at the basic ui it looks like this is using some subscription service instead of receiving all updates.
Correct me if I’m wrong but wouldn’t it be something useful for habpanel too, to make it perform better and let it use less cpu?

Powerful enough?

I run HABPanel on a MacPro. 6 cores of Intel Xeon (Admittedly circa 2013) and 32GB of RAM.

There’s no way the slowness of HABPanel is due to not enough CPU.

I can’t judge on the performance of your setup but what I want to point out is; is it necessary to receive all updates of all items from openhab in habpanel.
Random example: let’s say I use 40 items in my habpanel and my installation contains 400 items.
That means that I receive 90% on overhead on item updates that habpanel doesn’t need.

That’s why I’m curious if it is not possible to work with some kind of subscription service so you only receive updates of items that you have present in your habpanel.

I’m using habpanel on a tablet (Lenovo Tab 4) and the battery drains way faster when habpanel is opened compared to when basicui is open.

You’re right, but that’s because sitemaps are designed on the server so the system knows exactly which items are in it and can prepare a subscription accordingly. HABPanel works only on the client side, so the only way to have a complete state of the system is to retrieve all the items then update them using the rest/events endpoint. There’s no way to filter events with the current API.

If you can and feel up to it, try to follow this: https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/ and eventually post screenshots, you probably have a busy system with frequent updates but maybe there’s an obvious bottleneck too.

Hi All

I spoke a little too soon. My items are still taking 3500 ms to load, locally.

How do I dig deeper into the items to determine why? if I rename the echodot.items file, it loads fast so its something within this file but how do I work out which item?

Regrds

Have you been able to solve your performance issues?

I also have a performance issue on Habpanel.
I am running OH2.4 (openhabian) on a Raspi3.
Habpanel is displayed via Fully Kiosk browser on a ACER tablet, Android 6.0, 2GB RAM.
On Habpanel I show besides some Buttons a chart with solar power gains, my power consumption and what I get or put ito the public power network. These are 5 lines displayed. I also have a clock with seconds in the display.
After startup everything works fine, sometimes the clock looses one second, but response on buttons is ok. RAM usage of the tablet is at 1.2GB of 1.9GB total usable.
After a day or so the display gets more or less stuck, the 1.9GB RAM are fully used, the clock ist jumping in 30…40 sec steps.
Next step I decided to remove 3 items from the graph, so having only 2 in display.
With this setup I have no problem, maybe time is max jumping 2…3 sec.
So somehow the graph is eating up memory until game over. Is this a known issue? What can be done?
After a restart of the tablet everything is ok again.

On a WIN10 PC with old Core i5 and 4GB RAM I observe the same behavior.
Running Habpanel in Firefox (and some other open tabs) I started with Firefox consuming 900MB and after 2h it was 2.9GB! So same issue.

Holger