Univention Bugzilla – Bug 32096
Performance optimizations for syntax lookups
Last modified: 2020-08-21 09:11:49 CEST
Try to get as many syntax classes to not use_objects as possible! +++ This bug was initially created as a clone of Bug #30991 +++ Opening the UDM users or computers module takes "very" long. groups/group.py#open() does not seem to be the culprit, since a "udm users/user list --filter uid=XXXXXX" from the command line is instant (<0.5s). "udm groups/group list" on the other hand takes 11 seconds, which matches roughly the time UMC UDM takes. 1213 groups. No groups in groups. No mixed hosts / users groups. The largest group has 3572 users. The user is member of 26 groups with 16,17²,21²,22,25,39,67,78,88,112,119³,121²,137,144,176,251,1945,2814,2872,3296,3572 members.
A customer with large environment ran into this problem. The UDM module had to be modified manually to get it fast (time difference in opening an UDM object: 60 seconds vs. 1 second). #2014020721001793
(In reply to Sönke Schwardt-Krummrich from comment #1) > A customer with large environment ran into this problem. The UDM module had > to be modified manually to get it fast (time difference in opening an UDM > object: > 60 seconds vs. 1 second). #2014020721001793 Modified customer environment again after update to UCS 3.2. Would be great, if these optimizations will be added to UCS 4.
Maybe Bug #34070 has to be fixed first.
Is this still unfixed in UCS 4.1? My guess is that the reload(syntax) causes that issubcluss/isinstance(foo, UDM_Objects) causes to return False as the original instance doesn't exists anymore.
(In reply to Florian Best from comment #4) wrong bug...
Affected syntax classes are: import univention.admin.syntax import inspect slow = inspect.getmembers(univention.admin.syntax, lambda member: getattr(member, 'use_objects', False)) names = [x[1].name for x in slow] print '\n'.join(names) HostDN IComputer_FQDN LDAP_Server MailHomeServer PrinterNames PrinterProducerList Printers Service ServiceMail ServicePrint ServicePrint_FQDN UCSSchool_Server_DN UDM_Objects UMC_OperationSet UserMailAddress Windows_Server dhcpService nagiosHostsEnabledDn nagiosServiceDn network samlserviceprovider uccImage uccSessions
git grep -E 'syntax.\<(HostDN|IComputer_FQDN|LDAP_Server|MailHomeServer|PrinterNames|PrinterProducerList|Printers|Service|ServiceMail|ServicePrint|ServicePrint_FQDN|UCSSchool_Server_DN|UDM_Objects|UMC_OperationSet|UserMailAddress|Wind ows_Server|dhcpService|nagiosHostsEnabledDn|nagiosServiceDn|network|samlserviceprovider|uccImage|uccSessions)\>' $(find -name '*.py')
Sönke, is it still relevant for the customer? If so, can you explain which lookup is too slow so that we can focus on the relevant syntax.
There is a Customer ID set so I set the flag "Enterprise Customer affected".
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018. Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.
This happend again in a school customer environment. The customer installed kopano for testing, but decided not to use it, so he deinstalled the app. After that, it takes more than 30 seconds to open one user. There is a proxy/loadbalancer which "cuts" the request after the 30 seconds. Without that the request taken 40 seconds. So for the customer there are some few possibilities. * He can adjust his proxy (for him better to less than 30 seconds, so he does not need to wait so long) * He can remove all kopano attributes from his over 2000 users and remove kopano completely * Or we can fix this issue.
Did you try Florians suggestion and removed the Kopano extended attribute that uses the problematic LDAP_Search syntax?
(In reply to Erik Damrose from comment #12) > Did you try Florians suggestion and removed the Kopano extended attribute > that uses the problematic LDAP_Search syntax? No, I don't know which one it is, and I also have no idea how to find out.
(In reply to Christina Scheinig from comment #13) > (In reply to Erik Damrose from comment #12) > > Did you try Florians suggestion and removed the Kopano extended attribute > > that uses the problematic LDAP_Search syntax? > > No, I don't know which one it is, and I also have no idea how to find out. udm settings/extended_attribute list | grep -C 20 LDAP_Search → search for kopano. Let's not discuss this here.
(In reply to Florian Best from comment #14) > (In reply to Christina Scheinig from comment #13) > > (In reply to Erik Damrose from comment #12) > > > Did you try Florians suggestion and removed the Kopano extended attribute > > > that uses the problematic LDAP_Search syntax? > > > > No, I don't know which one it is, and I also have no idea how to find out. > > udm settings/extended_attribute list | grep -C 20 LDAP_Search → search for > kopano. > Let's not discuss this here. Thank you for your help! So, just for completion, we found the causing extended attribute, and removed it from the users/user module. udm settings/extended_attribute modify --dn 'cn=SendAsPrivilege,cn=kopano,cn=custom attributes,cn=univention,dc=schein,dc=kop' --remove 'module=users/user'