Yep… Just try to develop a new rule… That drives me total crazy if you hit run and then you change something small. Oh, forget something and hit again run and wait…
As you can see memory usage is 100% and swap usage is 10%, which indicates that the system does not have enough memory. Using swap instead of memory can heavily affect overall performance.
I think @rlkoshak wrote a more extensive post about this topic, but I cannot find it currently …
Ok, this mean, more or less, that the “old PI3” can not more used for an default installation with 4.02 to get a propper UI performance and a quick tasking from the rules. So a clear recommentation for a PI4!
Thanks!
As with most things it depends. If all you are running is OH 3 with a modest configuration an RPi 3 is probably fine. If you have ZRAM configured and running InfluxDB, Mosquitto, and NodeRed an RPi 3 is probably not enough.
1 Like
Thanks Rick 
I only recommend this to the Users which maybe not have it on their
shopping list, that when they upgrade from a OH 3.4x System to an OH 4.0x which was running on an
PI3, that they shall order an PI4, that is running smoove again as was in past …
Order already done for me…
Some update:
New HW has arreived:
Funny thing ist, that I have a 1:1 copy from my configuration. The production system and a testsystem.
Different is only the on the testsystem all rules a deactivated.
On the production (with the new HW) the rules are slower that on 4.0.2 and the testsystem (with the current used hw for pro) the rules are much, much slower ~ feeling ~3 times.
So for me it seems, that from 3.4.4 to 4.0.3 something has been changed in this way, that ist blocking a fast run from the rules. Also the hint from open,edit,close, and run the rule is NOT making the rule faster.
Here the config:
New Prodsystem:
###############################################################################
############### openhabian ##################################################
###############################################################################
## Ip = 192.168.xxx.xxx
## Release = Raspbian GNU/Linux 11 (bullseye)
## Kernel = Linux 6.1.21-v8+
## Platform = Raspberry Pi 4 Model B Rev 1.1
## Uptime = 0 day(s). 0:43:18
## CPU Usage = 2.27% avg over 4 cpu(s) (4 core(s) x 1 socket(s))
## CPU Load = 1m: 0.15, 5m: 0.30, 15m: 0.31
## Memory = Free: 1.62GB (43%), Used: 2.13GB (57%), Total: 3.75GB
## Swap = Free: 2.99GB (100%), Used: 0.00GB (0%), Total: 2.99GB
## Root = Free: 20.20GB (72%), Used: 7.55GB (28%), Total: 28.98GB
## Updates = 5 apt updates available.
## Sessions = 1 session(s)
## Processes = 132 running processes of 32768 maximum processes
###############################################################################
Testsystem:
###############################################################################
############### openhabian ##################################################
###############################################################################
## Ip = 192.168.xxx.xxx
## Release = Raspbian GNU/Linux 11 (bullseye)
## Kernel = Linux 6.1.21-v8+
## Platform = Raspberry Pi 4 Model B Rev 1.1
## Uptime = 0 day(s). 12:1:8
## CPU Usage = 12% avg over 4 cpu(s) (4 core(s) x 1 socket(s))
## CPU Load = 1m: 0.68, 5m: 0.49, 15m: 0.42
## Memory = Free: 1.33GB (36%), Used: 2.41GB (64%), Total: 3.75GB
## Swap = Free: 2.99GB (100%), Used: 0.00GB (0%), Total: 2.99GB
## Root = Free: 20.10GB (72%), Used: 7.66GB (28%), Total: 28.98GB
## Updates = 0 apt updates available.
## Sessions = 1 session(s)
## Processes = 130 running processes of 32768 maximum processes
###############################################################################
But nothing in JS Scripting has changed from 4.0.2 to 4.0.3.
Could you please check if the performance is better with „Use Included Library“ disabled?
Hello florian-h05
I’m not talking about a issue in performace between 4.0.3 and 4.0.2
Rich says it’s the old HW (Pi3), so I orderd a new one Pi4 and still have the issue,
that rules that where running in 3.4.4 are now much slower in my prod system, and much much much slower in my testsystem. As told, it’s an 1:1 image copy and only the rules are disabled all on the testsystem.
I disabeld, the „Use Included Library“ in the JavaScript Scripting Binding settings.
Restarted OH, and the speed is the same was ist was. Not real a good performance.
I noticed that GraalVM is slow on first run rule after start system or edit rule, but NashornJS is fast, but Nashorn is deprecated (
Important changes:
- Java 17 instead of Java 11
- GraalVM instead of Nashorn
You could try to install the Nashorn addon and run your Rules with it, so you could compare the speed.
WOW… This is the magic trick…
- deinstalled JavaScript Scripting Binding
- installed JavaScript Scripting (Nashorn) Binding
Now the speed is back as it was under 3.4.4.
But what now to do, when Nashorn is outdated?
PS: This is then also something which should be recommened in the release notes as impact for the users, which want to upgrade from 3x to 4x, that rules run slower after migration.
Who could take care to talk with those GraalVM devlopers, that we have an speed issue here???
You!
Everybody experience issues can report those to the according project.
It was not openHAB removing Nashorn from Java 17….
We are not promoting this so called solution as it has side effects: newer JS functions included in GraalVM are not available in Nashorn!
Will try as an normal user to make same awarenes…Exciting as normal user here…
And with Nashorn JS several users had problems when messing around with Java types in JS. The Graal VM based add-on includes an extensive helper library, which allows a “JS-only and don’t mess around with Java types” experience.
You can disable the automatic injection of that library (“Do Not Use Globals”) and you will get great performance. Graal VM is only slow, because of the injection of that library, which has a pretty large code base.
I am sure that if you would try to load that code base from Nashorn JS (which would not even work as Nashorn does not support CommonJS module loading!!) Nashorn would also be really slow.
2 Likes
Wow… now we are back on track.
When disable (“Do Not Use Globals”) it works fantastic
Are there any impacts so far known to rules when the flag is off?
Why all this kind ping pong here, when it is only a flag which need to be set, that also OH 4 Installations runs smoove again. If I would get the hint some weeks earlier, I would not have ordered a new PI for this problem and saved over 100€ … nice.
Can please the flag be set off by default and next updates by OH?
No, because this is first a breaking change and second if you need access to the APIs provided by the helper library (most people will use that on Graal because this is what the docs describe - and Blockly also needs it), you need to import them anyway, so then performance will be affected anyway.
The helper library makes life much easier, if you do not need it do not use it, but then do not expect that there are many people who can and want to help you when working with the raw Java types and APIs.
If you want or need to use it, you need to accept the performance decrase.
I have tried everything that came to my mind to speed up the library injection, and e.g. for @stefan.hoehn it worked fine on his Pi 4 when I asked him to test it, there were some major performance improvements.
Hmmm…
you wrote, that “Blockly also needs it”. What does this mean now?
When (“Do Not Use Globals”) is flagged off, the dsl and javascript rule run fast, but not more my Blockly???
I’m pretty sure I didn’t on this thread. But yes, with 0% RAM free, 22% of swap in use, and system loads > 1 that machine was overloaded and not sufficient to run everything you had running on it.
But I also said numerous times in this thread that the first time a rule runs is going to take significantly longer than subsequent runs.
In addition to what’s already been said, the import of the library will need to be manually added to each and every Script Action/Condition in MainUI. Across an average set of rules, up to 20% of all your code in UI Script Actions/Conditions will become the same line(s) of code over and over to import the library.
It also doesn’t seem to be universal which is weird. Not everyone is seeing such a huge reduction in performance I think. Some for sure but not to this extent. I wonder what the pattern is.
Correct. Blockly “compiles” to JS Scripting code that assumes that the auto injection of the library is enabled. If you disable that option, Blockly code will not work.
The library is not injected into the rules just because. It provides functionality, functionality that Blockly developed Script Actions/Conditions require.
2 Likes
GraalVM developer here Can you maybe explain a bit more in detail how you use GraalVM’s JavaScript engine? My assumption is you just include the graal.js-JAR into your project (which technically works, but will be horribly slow as you experience). To get good performance, you will need to run on GraalVM as your Java VM (not on OpenJDK, etc.).
3 Likes
Given the architecture of openHAB, running it as a separate process would not work as an openHAB add-on. And unless GraalVM can support Jav 17, run Karaf and all the OSGi services and all the other add-ons that openHAB supports on Windows, iOS, Linux (x64 and the types of ARM processors found in SBCs like Raspberry Pis), I don’t know how feasible it would be to run that way.
Of course the JS Sripting engine could be written as a separate outside service that interacts with OH the same as HABPanel does, but in that case we may as well just use node.js directly. That also wouldn’t work with Blockly (maybe there could be a way to make it work somehow but it would be weird) nor would it be that user friendly.
To get into some weeds…
openHAB runs on top Java 17 in Apache Karaf. All parts of OH are deployed as OSGi bundles including add-ons and the add-ons interact with OH via a Java API.
openHAB core provides a framework for triggering rules based on events, again based on a Java API.
The JS Scripting add-on provides GraalVM JS. Like other parts of OH, it is deployed as an OSGi bundle. Not all instances of OH include GraalVM JS. It’s installed by choice by the end users. The add-on bridges between the OH Java API and scripts (i.e. rules) written by the end users, making available OH services to the scripts and executing the rules/scripts when told to by the OH core rules engine.
Users must be able to develop and run rules at runtime. Requiring a restart of OH to compile the rules is a no-go.
I haven’t looked but we also need to be careful about licensing.
It seems like a lot of this can be handled but I don’t know that all of it can.
And of course, one of the add-on developers can provide even more details.