Event bus overheads
Large numbers of Item updates on openHAB event bus will obviously cause system workload to increase - while it carries out the actual update, looks to see if any rules should be triggered, performs logging, etc.
There is little that we, as users, can do to make this part more efficient.
Logging
I do not suggest reducing logging levels just to try and lighten the load. In any case, openHAB2 does not log “same state” Item updates with ordinary settings, only changes. You’ve got logging because you might need it, and while there is some overhead in system I/O writing to files it is fairly minimal.
We will look later at reducing the events themselves, though.
Having said that, do remember that you can generate extra log traffic by using trace level log settings to analyse some problem. Just remember to restore normal logging when your investigations are over!
Rules
You may wish to review your rule triggers in particular. For example, a rule that performs some calculation based on a temperature sensor Item could be triggered by Item update. It works, of course – but is it necessary to calculate every second? Would a changed type trigger give you the same result, but avoid the unnecessary overhead of running the rule every second to get the same value?
You may occasionally write rules that initiate some time-based action in response to a Modbus generated event. Take care that your rules logic does not build a big stack of timers etc. if updates may arrive quicker than actions are performed.
Persistence
This area has caused people noticeable problems, so it is worth your attention.
It is all too easy to configure your persistence service(s) to store every update for every Item. Where you have a hundred updates a second, this can present a substantial system load updating database files, particularly with slower storage media like SD cards
Review what you are storing, and when. everyChange or everyMinute strategies may be more appropriate than everyUpdate.
If you routinely persist all/many Items for restoreOnStartup purposes, consider if that is sensible for Modbus polled data Items. The binding should be working and polling data before your rules get going; so restoreOnStartup becomes pointless for polled data. (Note that the binding will poll all read Things at startup, regardless of the chosen polling refresh rate.)
There isn’t much more we can do to reduce the impact of many frequent Item updates. We should also look at ways to actually reduce the number of updates altogether.