What is the latest KB you have installed?

Vernon

Thanks for replying.

It may have helped if I included this in my original post, so will make sure I do for any future ones made.

The version we are using is 4.5 1370, which from researching a little more this morning includes the new Identify Service.

What I dont understand is whether I can automate the refreshing of this cache, or whether K2 can be configured to do this automatically, rather than waiting for the user to initiate the cache rebuild.

Gareth

I thought I would give people an update on this issue we were/are facing with K2.

To overcome this issue we have increased the amount of time the cache for users and groups is valid for. And triggered a cache rebuild on a Saturday.

This essentially means K2 will rebuild the users cache and any group membership over the weekend. Due to our large and complex AD forest this does take a fair amount of time, we were not very clever when considering future impact of nested groupings!

We also configured the cache to not expire for 7 days, meaning users will get a better response throughout the week. The downside to this is that any group changes occurring mid week will not be reflected in K2, however this has improved our overall load times of K2 each day from 6 minutes to around 30 seconds. So a big improvements.

Moving forward, we are actually in the process of consolidating our AD structure into 1 single domain which should drastically increase the effeciency of K2. The only problem is that this will not occur for at least another year due to the size.

If you need more information on how I did this, please let me know and I will write another followup post.

Best Regards,

For a large organization you would need a mechanism that allows you to manually refresh per user by admin (or even by user) - e.g. if someone changes position within company and should no longer have access to certain workitems.

How are you triggering refresh on Sat.?   Is that a special job K2 provided?

Hello, I am also interested in the general ideas behind your solution, if you can't give the specifics.

How was the job scheduled to run, what starts the process?

How does the cache rebuild work?  K2 API calls?

Thanks, Jason.

As a few people have asked for the process in which we managed this, I have included the details below. In all it is rather straight forward.

NOTE: Before following these, please check with K2 Support or Test in a development environment first. The last thing I wont to happen is your environments breaks because of my bad advice!

Force Rebuild of Cache at Specific Time

1. Create a SQL Job to expire any active indentify objects in the indentity cache database. I set up a job to run every Saturday at 7am. Have the job run the command below

UPDATE [Identity].[Identity] SET ExpireOn = GETDATE(), ContainersExpireOn = GETDATE(), MembersExpireOn = GETDATE()  WHERE Enabled = 1 

2. Change the following setting in the Indentity.CacheConfiguration database.

ResolvedExpiredIdentities: 15m

Around 15 minutes after the job is complete K2 should have started the process to rebuild any expired objects within the cache database. Due to our complex AD structure (15 domains) and overly nested groups this may take a huge amount of time. I am unsure how long exactly but can guess around half a day. This is the reason I run it on a Saturday morning. This leads me onto cache timeouts.

Increase Cache Timeouts

2. Increase the following parameters in the Indentity.CacheConfiguration database.

GroupContainersCacheTimeout: 169h
RoleContainersCacheTimeout: 169h
UserContainersCacheTimeout: 169h

This will ensure any cache that was rebuilt over the weekend lasts just over 7 days.

Some notes to consider

Before this was implemented we had users who every morning would face a long initial load of K2 of around 3-6 minutes. The reason for this was not only the fact that some of our AD controllers were not replicated to our datacentre but also because many of our users are in multiple groups which can span all of the domains. Plus these groups can be nested within other AD groups. A good example is myself. I am in 40 top level groups, but if we included nested groups then it shoots up to around 350+ across all domains. This also has an affect on my Kerberos ticket size, but this is a different topic.

I hope this is useful for somebody and we have now seen an improvement in initial loads times from 6 minutes to around 35 seconds. There is still some work to be done to improve further but at least it is a step in the right direction. I am hoping our AD redesign will help with this. We are moving from 2 forests (25+ domains) to a single forest and multiple OUs.

Best Regards,

Gareth

Gareth, thank you for the post, very interesting.

Thanks Again, Jason.