Rrdj4 performance (OH 2.x)

Setup, Configuration and Use Runtime
1

I’m seeing a bit of activity (bug fixes) on GitHub around RRDJ4 performance with items with dimensions tied to them for OH 3.x.

Are there any changes to the RRDJ4 binding for OH 2.x users around this?

I use RRDJ4 quite heavily with over 1000 rrdj4 files active on my implementation.

Any change that can increase performance of this add-on would be appreciated for the OH 2.x implementation.

Please advice.

Best, Jay

2

I don’t think that the changes will be made available for OH2 (THINK!)

On the actual topics you have read:
The performance issue that is worked on was observed on the updated version after an change on the updated version. IOW for the rrd4j version in OH2 there is no reported perfomance issue. The problem on the new version is related to items with a dimension, the old version does NOT support that all. Additionally the performance issue was only observed on a device with “constrained resources”.
If you do observe performance issue I’d wouldsuggedt to file an issue. Even if that one will not be worked on (ATM?), maintainers would be notified.
Personally I would not be surprised to see performence issues ona private system persisting more the 1000 items (any service!)!

3

@jwiseman Sorry, no chance. As @opus correctly says, the performance issues that were just fixed were introduced by a recent change, so the result is not any faster than what you have on 2.x.

Also note that 2.x actually does not have any persistence services, but all of them are coming from 1.x and being used through the compatibility-layer - and the 1.x repo is fully out of maintenance. Therefore if any improvements are done, those will only happen on 3.x.

1 Like
4

Thanks for getting back on this quickly.

Just to clearly understand, these numerous items below in my OH 2.4 implementation (rrdj4 using the 1.x compatibility layer) has NO performance issues below that you are aware of?

Number:Dimensionless
Number:Temperature
Number:Pressure
Number:Speed
Number:Angle
Number:Length

Best, Jay

5

The dimension/unit is simply ignored by pre-OH3 persistence.
They’re stored and retrieved as plain numbers.

Note that you can get surprises; storing "1500 W’ stores 1500. If you later restore, but the Item currently has a kW unit, you get “1500 kW”.

4 Likes
6

For the average user like me openHAB is slowly becoming too complicate. This is sad …
I noticed this not only in this thread, also on many of the other threads.

7

The surprise here would be the result of using UOM (invented after OH2) with persistence services of OH2.
I expect this to work properly and seamlessly under OH3.

You don’t have to burden yourself with new features. There are OH 1.8.3 systems still running out there.

1 Like
8

You are absolutely correct. That “surprise” referred to a setup where openHAB 3 features are used in conjunction with a 1.x persistence service.