I checked for previous posts - most are 7 years old.

BACKGROUND

We have noticed our LDAP Cache refresh time has begun to significantly increase.

Looking for input from other SSC operators - how long does your LDAP cache refresh take? Any palliatives you used to reduce it?

Our is 30+ minutes.

Our biggest request is for SSC to be able to SKIP LDAP Cache refresh on reboot - and to simply perform it "on schedule".

Why? Every time we reboot SSC (upgrade, Kubernetes reboots it) we face 30 mins delay to use the system.

SSC SIZE

We have a single SSC:

• approx 11TB
• 15k projects
• 56k versions.
• 11,5k LDAP entities, of which ~500 are groups
  • a series of search paths
• 180 local users

The LDAP cache refresh has started to become excessive.

EXPERIMENTS

local v ldap

MicroFocus suggested it could be that we have some duplicate local/ldap users.

Anyhow hit such an issue?

Given the search is local, then LDAP ... surely if I have a duplicate then it should find it in the 180 users FIRST. That has to be very quick lookup?

Dev v prod

Dev server, a close copy of prod, refreshes in 10 mins. So 3x faster.

But less users on the system.

Staging (with prod copy) v prod

Hits the issue! So something to do with the size of our DB?

Testing just the LDAP part

We created a new temp server. I migrated all of the LDAP users to system. 3 minutes refresh.

Then I added the GROUPs, 8 minute refresh.

Finally I added some duplicate local users .. 8 minutes refresh.

CONCLUSIONS

I dont believe that duplicate local/ldap users is causing the peformance drop.

I do not believe it is the lookup time to our LDAP server - well that is I seems to be 8 minutes on a near empty project/version SSC.

So I have to conclude that as part of the LDAP Cache refresh there must be some interaction between the LDAP Entries and the project/version users?
But I have no clean test of this.

I plan to migrate projects from our staging to the temp system and see if the LDAP Cache refresh time increases.

Any thoughts appreciated.