openhab / openhab-webui

Web UIs of openHAB
Eclipse Public License 2.0
221 stars 239 forks source link

[MainUI] rules list unresponsive when large number of Rules #2593

Closed jpg0 closed 4 months ago

jpg0 commented 5 months ago

The problem

I have a large number of rules (currently 697) and the rules list in the main UI is becoming unusable. It fails entirely on phones, and repeatedly hangs when scrolling on a (fast) laptop. The items list (which has more elements in it) is fine.

Expected behavior

Rules list behaves the same way as items list.

Steps to reproduce

  1. Create a large number of rules
  2. Try to view the list on a phone, or load on a laptop and scroll very quickly through the list

Your environment

runtimeInfo:
  version: 4.1.2
  buildString: Release Build
locale: en-AU
systemInfo:
  configFolder: /openhab/conf
  userdataFolder: /openhab/userdata
  logFolder: /openhab/userdata/logs
  javaVersion: 17.0.11
  javaVendor: Debian
  osName: Linux
  osVersion: 4.9.277-122
  osArchitecture: aarch64
  availableProcessors: 6
  freeMemory: 299810928
  totalMemory: 975175680
  uptime: 599275
  startLevel: 70
addons:
  - binding-astro
  - binding-fronius
  - binding-hpprinter
  - binding-icalendar
  - binding-melcloud
  - binding-mqtt
  - binding-openuv
  - binding-sonos
  - binding-surepetcare
  - binding-telegram
  - persistence-influxdb
  - transformation-jinja
  - transformation-jsonpath
  - transformation-map
  - ui-basic
  - ui-habpanel
clientInfo:
  device:
    ios: false
    android: false
    androidChrome: false
    desktop: true
    iphone: false
    ipod: false
    ipad: false
    edge: false
    ie: false
    firefox: false
    macos: true
    windows: false
    cordova: false
    phonegap: false
    electron: false
    nwjs: false
    webView: false
    webview: false
    standalone: false
    os: macos
    pixelRatio: 2.200000047683716
    prefersColorScheme: dark
  isSecureContext: true
  locationbarVisible: true
  menubarVisible: true
  navigator:
    cookieEnabled: true
    deviceMemory: 8
    hardwareConcurrency: 10
    language: en-US
    languages:
      - en-US
      - en
    onLine: true
    platform: MacIntel
  screen:
    width: 1512
    height: 982
    colorDepth: 30
  support:
    touch: false
    pointerEvents: true
    observer: true
    passiveListener: true
    gestures: false
    intersectionObserver: true
  themeOptions:
    dark: dark
    filled: true
    pageTransitionAnimation: default
    bars: light
    homeNavbar: default
    homeBackground: default
    expandableCardAnimation: default
  userAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36
    (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36
timestamp: 2024-05-29T03:20:56.017Z

Browser console

Browser network traffic

Additional information

jpg0 commented 4 months ago

I tried disabling the event streaming for the rules UI - this completely fixed the issue for me (I'll leave it like this for the time being as the UI is inoperable otherwise). So the performance woes appear to originate from the event streaming.

rkoshak commented 4 months ago

That's a good find I think.

MainUI will change the badge of the rules based on it's current state and it knows the current state through the event streaming. It seems odd though that it causes problems with rules but not Things. Surely some people have hundreds of Things. I do know that event streaming is already turned off for Settings -> Items, perhaps to address this same problem.

I wonder if event streaming for Rules and Things needs to have an option that can be enabled/disabled (perhaps under Help & About ?)) or have some sort of condition where it gets disabled automatically if you have more than say 100 of them. Pagination could be another approach to limit how many events the page needs to subscribe to and process.

jpg0 commented 4 months ago

I am aware that things are implemented slightly differently with items compared to rules, but I'm not sure why it's so slow. With rules it literally brings may (macbook pro m1) browser to a halt. Given that it's streaming related, it may also be a factor of how much is going on in the stream in addition to the number of rules.

Hundreds of items isn't really that huge for a page though, I'd expect that this should be able to be solved if we really want to. I agree that limits would be a reasonable quick-fix however - seeing the status of a rule is rarely something that matters to me.

florian-h05 commented 4 months ago

I tried disabling the event streaming for the rules UI - this completely fixed the issue for me

Does the issue also disappear when only removing

https://github.com/openhab/openhab-webui/blob/fa1d5265100e8cc6c12f0e079bc508e42d6e0b7d/bundles/org.openhab.ui/web/src/pages/settings/rules/rules-list.vue#L268-L274

I would like to pinpoint the exact problem and I suspect the problem is the .find call, which is in O(n) where n is the number of rules. If this is the cause of the problem, I will refactor the state tracking to use a separate object or map, so we should get O(1) for access to the Thing state to change it.

I do know that event streaming is already turned off for Settings -> Items, perhaps to address this same problem.

AFAIK it never has been in place there, but I can confirm that event streaming for Items causes real performance issues, I have tested this some time ago.

Given that it's streaming related, it may also be a factor of how much is going on in the stream in addition to the number of rules.

I suspect this is the reason the event streaming becomes an issue. For the Things page, there is likely not going on much in the stream, Thing states change not really often.

But for rules, there is likely a lot of status changes going on, which makes the issue occur.

florian-h05 commented 4 months ago

@jpg0 I went ahead and opened #2623. Can you please test https://github.com/openhab/openhab-webui/pull/2623#issuecomment-2186656874?