Slow MainUI when having enough items

Platform information:

Hardware: Raspberry Pi 2 Model B Rev 1.1
OS: Raspbian GNU/Linux 10 (buster)
openHABian: openHAB3 Branch
Java Runtime Environment:
openjdk version “11.0.11” 2021-04-20
OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
OpenJDK Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mod
openHAB version: openHAB 3.1.0


I recently installed the OpenWeatherMap binding which pretty much doubled the item count of my system from ~600 to 1281. Since then my MainUI is darn slow. I did a quick HTTP response time analysis and detected the call to /rest/items?metadata=semantics,listWidget,widgetOrder to be the culprit, taking ~7 sec to generate a response. This is pretty unfortunate since it’d be quite simple to just cache that service. >99% of the time the GUI is used to read and not to write items, so that fix seems quite obvious. Is there already a cache available but just not activated? Or am I the only one so far facing that type of performance problem?

What device(s) are you using to view the UI?

For me the MainUI is definitely slower than BasicUI was when I used that in OH2. But on my PC the UI is still fairly responsive, whilst on mobile it does struggle a bit.

(I’ve not tried BasicUI in OH3 to compare).

I’ve moved OH3 between various devices, some low powered, some stupidly high powered, but UI lagging tends to be tied to the device that is rendering the UI, for me. Of course, a Pi2 is probably stretching things for your OH3 install!

It’s not really a rendering issue but a backend issue observable by just using curl for example.

You’re certainly right about my PI2, but it performs well enough for me for all other use cases except that one items call.

Out of curiosity, can you issue the following call in a console

time curl "http://openhabian:8080/rest/items?metadata=semantics,listWidget,widgetOrder" --output /dev/null

and tell me the output plus the HW you’re running OH on and current item count? That’d be very interesting.

This is my result:


Running that command from another device on my network, routing to OH3 through WiFi:

real    0m0.279s
user    0m0.023s
sys     0m0.035s

I only have 429 Items, manually defined in Items files.

My OH3 is currently running in a Proxmox LXC, on this hardware.

(Note, I’m running pure openHAB from the repositories on an Ubuntu OS, not openhabian)

:grinning_face_with_smiling_eyes: ok, can’t compare with that hardware. A PI4 would be interesting, since that’d be a possible alternative for me. Or just a simple items cache :slightly_smiling_face:

I can try running this command on my RPi4 (4GB) later today, but I also have far fewer items. I’d agree that the RPi 2 probably isn’t cutting it.

You have 681 OWM items? That seems kind of insane, but I don’t know what your use case is. I don’t care about forecasts (I get those from Google), so I’m only using about 12 OWM items to display current conditions.

cough probably got default persistence churning away on those 600 extras as well :wink:

1 Like

Here are my results, from a Windows PC over WiFi (with my Pi4 connected by Ethernet). I only have 170 items in total, mostly defined in MainUI.

real    0m0.050s
user    0m0.022s
sys     0m0.020s

What I didn’t mention: I’m using h2 database in embedded mode as persistence.

I gathered some new facts using h2 tracing:
The bottleneck is iterating over the jdbc ResultSet created by the query “SELECT itemid, itemname FROM items;”. The query itself is executed in 184ms. Iterating over ResultSet takes ~6 seconds. We are talking about a ResultSet containing 1305 items.

I bet setting higher fetchSize on that PreparedStatement changes performance dramatically. Hope I’ll find time to test that soon.

I don’t have a solution, but certainly the same problem. I have a little over 1000 items and some parts of the UI are very slow. If I click on any item list, it will load for around half a minute.

I’m on a rpi3b+ OH3.2M3