Uploaded image for project: 'JBoss BRMS Platform'
  1. JBoss BRMS Platform
  2. RHBRMS-1930

Project authoring is getting significantly slower with increasing number of packages and rules

This issue belongs to an archived project. You can view it, but you can't modify it. Learn more

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Critical Critical
    • 6.1.0
    • 6.0.2
    • Business Central
    • None
    • DR4
    • Hide
      Possible Summary:

      Creating new rules and opening packages in the Project Explorer becomes rather slow in a project with a large quantity (1000s) of rules. Other packages and projects with a considerable amount of rules also affect the loading time of an independent package. This issue stems from a whole project rebuild that occurs whenever a .drl, .gdst, .rdrl, .rdslr, or .template file is created.


      Cause:

      Consequence:

      Fix:

      Result:
      Show
      Possible Summary: Creating new rules and opening packages in the Project Explorer becomes rather slow in a project with a large quantity (1000s) of rules. Other packages and projects with a considerable amount of rules also affect the loading time of an independent package. This issue stems from a whole project rebuild that occurs whenever a .drl, .gdst, .rdrl, .rdslr, or .template file is created. Cause: Consequence: Fix: Result:

      Description of problem:
      In a project with hundreds of rules certain operations become painfully slow. I would expect that building the complete kbase depends on the number of rules but some other operations should not be affected. The most obvious are creating new rules and opening package in Project Explorer.

      While a package with 100 rules loads under 2s, loading a package with 1000 rules takes 20s. Creating new rule in a project with 1000 takes ~15s. Saving a rule is done almost immediately but the incremental build running in the background blocks some other actions (like opening a different rule) for additional ~10s.

      All in all, in a project with ~1000 rules it is painful to work in Authoring perspective (navigate between packages, creating and opening rules). Considering that a single user can generate almost 100% CPU load bursts taking ~10s on the server side, the performance of Business Central should be thoroughly reviewed if it is intended to allow many users to work on large projects in parallel.

      Version-Release number of selected component (if applicable):
      6.0.2.ER3

      How reproducible:
      I have prepared a repository with different history branches leading to a project with either 1000 rules in a single package or 200 packages with 1 Java class, 2 rules and 1 process per package.

      Run 'git tag' to see available tags capturing the project in a certain state. You can easily switch the project state by resetting master branch to one of the tags and force pushing it to Business Central to examine how it performs.

      Steps to Reproduce:
      1. Go to Business Central, Administration perspective and create new empty repository, call it e.g. testrepo.
      2. Download and unzip attached repository, cd into it.
      3. Run 'git config -e' and change the remote "origin" to
      a) contain a user with 'admin' that you have configured on your BC instance,
      b) contain the empty repository you have created in BC and you want to push to.
      4. Run 'git tag' to see all available tags.
      5. Run 'git reset --hard pkg50' to reset master branch to tag pkg50 where the sample project contains 50 packages.
      6. Run 'git push -f origin master' to push current master branch to business central.
      7. Go to Project Authoring, switch to testrepo / leak-project.
      8. Experiment. Navigate to any leaf package. Create new DRL or guided rule, etc.
      9. Repeat from step 5 with a different tag to compare the performance.

      Actual results:
      See description.

      Expected results:

      • Loading a package content may depend on number of files in that package but shouldn't be affected by files in other packages/projects. It shouldn't take seconds even with 1000 rules.
      • Creating a new rule should complete (almost) immediately, independently on number of files that already exist in the current package/project.

      Additional info:

              manstis@redhat.com Michael Anstis
              jlocker Jiří Locker (Inactive)
              Archiver:
              rhn-support-ceverson Clark Everson
              Jiří Locker Jiří Locker (Inactive)
              Jiří Locker Jiří Locker (Inactive)
              Alessandro Lazarotti, etirelli, Lukáš Petrovický (Inactive), Rajesh Rajasekaran, Zuzka Krejčová (Inactive)

                Created:
                Updated:
                Resolved:
                Archived: