Learning maintenance: evaluate script moving users to a disabled group #363
Assignees
Comments
|
Tested on a local omero server with 61 users in 79 groups. The script is working without problems, the situation before The group with ID After the run of the script, the output of which is plausible imho. In summary, I think this is a very useful script. |
|
@sbesson : When consulting the workflow with @will-moore , an important consideration came up. If we delete users, and the deleted user is logging in again using LDAP, this will re-create their account and they will have no detrimental user experience. This is not a given for the workflow of the
|
|
The test on a local OMERO and OMERO.web clearly shows that
The RHP load speed is:
This is an improvement of more than order of magnitude, but mainly, it also completely restores the feeling of responsiveness in webclient for a user using the UI to acceptable levels. I think this shows that the script would be very useful, except for #363 (comment) |
|
Note that the slowness is not perceived by an admin which is not a member of the group where the data are located. |
|
A new idea: the #363 (comment) could be solved by forcing the |
|
Interesting and the approach makes sense to me. I assume we will have to handle the scenario where an archived LDAP user is recreated and archived a second time as it might lead to name conflict. Note the current maintenance process i.e. the deletion of old users with no associated data via a custom SQL script, meets the minimal requirements in terms of restoring performance of a system with a growing number of temporary users in a single group. The workflow discussed above would have the benefit of keeping the users in the DB which offers advantages mostly in terms of reporting as it allows to introspect historical data while collecting usage metrics. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The UoD SLS learning system is getting heavily used during the academic term with new students logging into the resource using their University credentials and being mapped into the default group containing the course supporting data to allow access - see
prod-playbooks/omero/learning.yml
Lines 57 to 61 in b2e0137
Eventually, many teaching semesters lead to the creation of several 100s of users in the single group. This causes performance degradation on the OMERO.web deployment as several of the queries start to run more slowly.
At the moment, the OME team runs periodically ad-hoc maintenance scripts on the system to reduce the number of users in the group. On the image.sc forum, a similar problem was discussed with a script being shared which allows to move stale users into a "graveyard" group - see https://forum.image.sc/t/omero-user-scripted-inactivation/70767/3.
For the next maintenance, we might want to evaluate whether this script could be adapted to the requirements of the SLS learning deployment and used to move students from the former year to another group to restore performance.
The text was updated successfully, but these errors were encountered: