Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Large number of changes and provisioning

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Large number of changes and provisioning

Chronological Thread 
  • From: Robert Bradley <>
  • To:
  • Subject: Re: [grouper-users] Large number of changes and provisioning
  • Date: Wed, 16 Aug 2017 17:48:15 +0100
  • Ironport-phdr: 9a23:EVWPKBGmOs4/52MR1VHotJ1GYnF86YWxBRYc798ds5kLTJ78r8+wAkXT6L1XgUPTWs2DsrQf2rqQ6/iocFdDyK7JiGoFfp1IWk1NouQttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXdrXKo8DEdBAj0OxZrKeTpAI7SiNm82/yv95HJbQhFgDmwbaluIBmqsA7cqtQYjYx+J6gr1xDHuGFIe+NYxWNpIVKcgRPx7dqu8ZBg7ipdpesv+9ZPXqvmcas4S6dYDCk9PGAu+MLrrxjDQhCR6XYaT24bjwBHAwnB7BH9Q5fxri73vfdz1SWGIcH7S60/VDK/5KlpVRDokj8KOSMn/mHZisJ+j6xVrxyuqBN934Hab5qYNOZ9c67HYd8WWWRMU8RXWidcAo28dYwPD+8ZMOhEqInyvEUBrQGiBQKxGe7v0CVHiWLy3aIk0+UqDAbL3BYnH90VrnvUtsn1OL0JXuCv1qbH0DHDYO1W2Drm6YjIbgotofaDXL5qa8Xe1VMjFx7GjliJr4HuIjCb1vwVvmSG7udtW/ijh3M9pw1vuDSj28YhhpfRio4I1FzJ8T91zYc3KNGiVUJ3fdCpHIFNuy2HOIZ7RN4pTXtytyYg0LIGvIa2fCgUx5QjwB7Sc+aHfJaM4h35VOedPDh1iGhgeL2lhhay9VKsyurzV8WuyllFsjBJksTPtnwV1hzT7NaISudl80u82DuC2Rrf5vxeLUwqj6bXNp8szqAompoWq0vDHyv2mEvsjK+Rc0Up4vKo6+P8bbr4vJ+cK5V4hRrkMqs0h8O/Bfo3MwgVUmia5eSwzrrj/ELjTLpQkvI6iLTZsJPCKcQBuqG5GxNV0pok6xunADemytMYnWQfLF1bYhKLlpXpO0rQL/DiFveymFCskDZwx/DaJb3tHI/BLnnFkLf9Y7l98UhcxxQvzdxB/Z5bFKwOIO+gEnP24dPCCQIhPhbx3v3qEs5V14UCVHiJD7PDdq7erAym/OUqdtOLboIPpH7XMfEp4/P/xSsjnlUQZ7Xv14EeZHS1D9xnPwOecTzliZEcEjFZ7UIFUOX2hQjaAnZobHGoUvdk6w==

Hash: SHA256

On 16/08/17 16:52, Dave Churchley wrote:
> Seems like a great idea to me. I hope you don’t mind me asking an
> off-topic (but definitely related) question…
> We’ve suffered from similar backlogs with PSP when there have been
> large membership changes. The first thing that struck me about your
> solution, however, was that you said your bulkSync takes half an
> hour. For us it takes about 2 weeks! For this reason, we never do a
> bulkSync and rely on PSP incremental provisioning to AD so when we
> get a backlog we just have to live with it.
> We’re on v2.2 using PSP to provision to AD. Since we started using
> PSP we’ve found it to be quite slow but, under normal load, it
> copes pretty well and updates AD in about a minute. We do
> occasionally suffer provisioning backlogs though. We know there’s a
> big one on the horizon at the end of the month, as our academic
> year switches over. Last year we had a backlog for about 2 weeks.
> Does anyone have any suggestions that might help us out? We’ve
> recently been testing PSPNG on v2.3 but it doesn’t appear to be
> quite production-ready for our needs yet.

Things I'd suggest from personal experience are:

1. Run the bulk sync after setting the following in

changeLog.psp.fullSync.omitDiffResponses = true
changeLog.psp.fullSync.omitSyncResponses = true

and setting logSpml="false" in psp-services.xml (within the <Service
... /> tags). These shouldn't directly affect performance, but does
reduce memory pressure and the GC overheads caused by it. If you can
increase the JVM -Xmx and -Xms parameters fairly easily, I'd recommend
doing that as well.


Increasing caching in ehcache.xml (both TTL and number of entries) can
help a lot by reducing round trips to your subject sources (AD?).

I'd also check the LDAP indexing of any subject or provisioned
attributes. In OpenLDAP terms, you'd ideally want "pres,eq" indexes
for attributes that aren't used by the Subject API search, and
"pres,sub,eq" indexes for those that are searchable. I'm assuming
that AD has similar index controls, but lack the experience with AD to

- --
Dr Robert Bradley
Identity and Access Management Team, IT Services, University of Oxford


Archive powered by MHonArc 2.6.19.

Top of Page