[Core] - ACL cache increases delays upon multiple actions on multiple users.
[Core] - ACL cache increases delays upon multiple actions on multiple users.
Requirements
It is possible the ACL cache is being drastically increased upon treatment of multiple users, creating a delay on the completion of a desired task.
_Simple example: Multiple users within multiple groups, change/modification is very slow. _
Descriptive title for this enhancement
[Core] - ACL cache increases delays upon multiple actions on multiple users.
Actual behavior
Processing of a large amount of users creates delays of process.
Expected behavior
A delay due to the amount of users being processed is to be expected, but must be reasonable.
Step by step description of new behaviour
Processing multiple users with whatever tasks required must not exceed a reasonable delay.
Benefits
Better ACL cache management.
Possible Drawbacks
None
Applicable Issues
Might be related to the following issue: Here
Activity
changed milestone to %FusionDirectory 1.4
added enhancement fusiondirectory-core labels
assigned to @tdockx
By dockx thibault on 2022-09-06T10:45:44 (imported from GitLab)
added PJ2110-0447 label
created branch
6229-core-acl-cache-increases-delays-upon-multiple-actions-on-multiple-usersto address this issueBy dockx thibault on 2022-09-06T10:47:09 (imported from GitLab)
It would seem a calling on object $ui -> getUserInfo () might be one of the culprit. The class return a lot of information based on the DN received. During the creation of a User (with Unix TAB) the existing session size is increased up to 11MB and is reduced directly after save. Repeating quickly, this process of user creation can increase the I/O disk drastically.
A possible solution would be to specialize the userInfo class in order to return only valuable information. A better granularity on its calling would be more than beneficial. There is no need to parse all sessions ACL cache of almost all users during the creation of a new User.
It would be interesting to see the possible gain of performances between a system running an NVMi(SSD) or HDD and compare the results.
The handling of the ACL cache within userInfo needs deep analysis to see if an enhancement would be beneficial. If the specialization of userInfo can occur, the cache ACL could remain untouched.
By dockx thibault on 2022-09-12T09:07:58 (imported from GitLab)
Edited by bmortierAs reported by Unamur University, whom potentially face identical problem, NVME storage type has no influence on the problem.
Troubleshooting note :
- $ui is populated thanks to $ui = userinfo::getLdapUser
- $ui->LoadACL in correlation with the above method fulfill the sessions with required info. (Maybe too much).
It has been thought that this logic could be applied to the logged-in user only. Therefore, applying privileges to that user only without storing / verifying others privileges.
Testing in progress.
By dockx thibault on 2022-09-28T08:05:11 (imported from GitLab)
Edited by bmortierNote of progress
After multiple tryout of reproducing the potential session size increase and slowness due to ACL verification, I was not able to have any difference in sense of time processing. Returning "RWCDM" within get_permissions method does not have any impact upon adding / modifying a user. Here a simple password modification of 8.000 users.
A new version of LSC OVA will be used to re-test once more in order to see if any difference occurs.
By dockx thibault on 2022-10-04T15:43:31 (imported from GitLab)
Closing here as it seems all delays and performances issues were due to either an Overlay or wrong LDAP configuration. (Non Orleans).
Issues with uniqueness function and methods within Supann-Ex plugin. (Orleans).By dockx thibault on 2023-01-26T09:31:58 (imported from GitLab)
Edited by bmortierremoved enhancement label
added Fixed label
