Created attachment 904626 [details] GIT repository containing project with thousands of files 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:
OK, some progress :) When the User selects items in Project Explorer we raise a ProjectContextChangeEvent CDI event to communicate a change in "context" to the client-side workbench. This event is also (unfortunately) also observed by a long-running server-side component. When the User makes multiple selections the HTTP channel between client and server becomes overloaded with outstanding long-running HTTP connections (caused by the long-running server-side process observing the CDI event). This leads to the Project Explorer's response time becoming next to use-less (as the browser is waiting for a HTTP connection to become free). Fortunately the long-running server-side component has already been identified in this BZ (it is the RuleNameServiceImpl, used to build lists of rule names to be used by "rule A extends rule B"). This component will need to be updated, as proposed, to use the Index service...
Much better. Project explorer navigation takes under 5s for each package change no matter if the new package contains 1000 rules or 200 packages. Creating and saving rules is finished almost immediately.