Any cap on livelink group creation?

Hi, The application design level involves the creation of livelink groups dynamically to maintain the ACL (permissions) for that LL Node (folder). With that design in place, the number of groups to be created will be 20000 during the initial environment setup and it's foreseen that it will grow with 5000 groups annually.It will be really appreciated if you folks answer to my questions below at the earliest. 1) Will it create any performance issues?. 2) Any lurking/fallout issues in future?.Thanks!.

Find more posts tagged with

Comments

Andrew_Kane

Message from Andrew Kane via eLinkWe have seen performance problems for some operations with 9000 groups.I'll try and get more information for you...-----Original Message-----From: eLink Discussion: Development Discussion[mailto:development@elinkkc.opentext.com] Sent: Friday, February 17, 2006 3:25 PMTo: eLink RecipientSubject: Any cap on livelink group creation?Any cap on livelink group creation?Posted by Sharma, Mahim on 02/17/2006 03:23 PMHi, The application design level involves the creation of livelink groupsdynamically to maintain the ACL (permissions) for that LL Node (folder).With that design in place, the number of groups to be created will be20000 during the initial environment setup and it's foreseen that itwill grow with 5000 groups annually.It will be really appreciated if you folks answer to my questions belowat the earliest. 1) Will it create any performance issues?. 2) Any lurking/fallout issues in future?.Thanks!.

Mahim_Sharma_(mahimsharma_-_(deleted))

Hi Andrew, Thanks for your support.Please elaborate more on the operations having the performance catch > 9000 groups and any other information on this case.

Andrew_Kane

Message from Andrew Kane via eLinkHere's how I think the permissions performance problems arise inLivelink (Note: This may differ from reality):You're basically doing a join (yes in the RDB) between the user'spermissions (including the transitive closure of the group memberships)(A) and the permissions of the objects being checked (B). When bothsides of this join are large you can run into performance problems.Most Livelink operations are similar to browse where permissions areco-located meaning B is small. There are a few exceptions to this,mostly search, classifications and dynamic classifications. These havethe added problem of usually presenting a fixed number of objects (forexample, 100 search results) from a large set. If the permissions arevery restrictive this drastically expands the number of objects checked(for example, 100 search results with 10% visible to the user would haveto check about 1000 objects).I believe there are some pre-computed optimizations for the permissionjoin, but they may need to get recomputed whenever you add/removegroups. This means adding or removing groups could cause permissions tobe temporarily slow, so this should be done at off peak times.In the example with 9000 groups some of the users where in 500 or moregroups. I believe the performance problems came up when combining thiswith many classifications accesses...FYI: One of our Livelink developers said, "We have customers with over200,000 groups."-----Original Message-----From: eLink Discussion: Development Discussion[mailto:development@elinkkc.opentext.com] Sent: Tuesday, February 21, 2006 2:28 PMTo: eLink RecipientSubject: Hi Andrew,Hi Andrew,Posted by Sharma, Mahim on 02/21/2006 02:22 PMHi Andrew, Thanks for your support.Please elaborate more on the operations having the performance catch >9000 groups and any other information on this case.[To reply to this thread, use your normal E-mail reply function.]============================================================