Bug 49862 - The initialization of the listener module portal_groups takes too long
The initialization of the listener module portal_groups takes too long
Status: NEW
Product: UCS
Classification: Unclassified
Component: Listener (univention-directory-listener)
UCS 4.4
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-07-17 11:04 CEST by Christina Scheinig
Modified: 2019-07-24 14:21 CEST (History)
3 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 5: Major Usability: Impairs usability in key scenarios
Who will be affected by this bug?: 1: Will affect a very few installed domains
How will those affected feel about the bug?: 5: Blocking further progress on the daily work
User Pain: 0.143
Enterprise Customer affected?:
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Ticket number: 2019071221000426
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christina Scheinig univentionstaff 2019-07-17 11:04:42 CEST
The initialization of the listener module portal_groups takes up to 12 hours in large environments (36000 groups). 
The listener builds its cache group by group the first time. The cache is written 36,000 times instead of calculating everything once at the end. 

We have to optimize that.

In this special environment we have the workaround, that this module can be deactivated  by setting the ucr varible listener/module/<name>/deactivate

This might not work on other environments.
Comment 1 Christina Scheinig univentionstaff 2019-07-24 14:21:10 CEST
I small update. The customer has concerns about the Listener module to cause a lot of trouble during the next import of the new user data at the end of the school year. Thus several Dozens of thousands of groups can be modified hundreds of times, so that the Listener module could also stop other modules (S4-Connector) here. 

That would be a big problem. If these concerns are justified, the customer would therefore like a short-term performance optimization for the module if possible.

Maybe it's enough to deactivate the module with the ucr variable again?