Performance Impacts Due to Number of Branches

*Using TS 6.5 on Solaris

Hello,

I know with TS 6.0, changes were made to the backing store that significantly improved performance limitations that were occurring when too many branches (or directories/files for that matter) were created on previous versions of TS. In our current architecture, we will be using TS 6.5 and are looking to have about 7 branches with each branch having a minimum of 50 and up to a maximum of about 1500 subbranches. Each subbranch would have only workarea.

There will only be one set of DCTs for all subbranches (e.g., each subbranch would have a copy of the same DCTs). However, we do not want to use multiple workareas in a single branch (instead of the subbranches), because each subbranch has it's own group of users and only that group can access the content for that subbranch (e.g., wouldn't be able to use "get latest" function)...not to mention potential overwrite issues.

Can anyone quantify the performance impacts this huge number may have on the system? I realize this probably would have been a major issue prior to 6.0 but am hoping that isn't the case with the new content store.

Thanks,

ab

Find more posts tagged with

Comments

Adam Stoller

However, we do not want to use multiple workareas in a single branch (instead of the subbranches), because each subbranch has it's own group of users and only that group can access the content for that subbranch (e.g., wouldn't be able to use "get latest" function)...not to mention potential overwrite issues.

I'd strongly encourage you not to try to have different workareas on the same branch contain different content -- if you cann't run Get Latest on a workarea there's something fundamentally wrong with your design (IMO).

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

abyrd

fish,

I agree with you 100%. We do not plan on using multiple workareas nor do we want to remove the 'get latest' functionality. However, since we will require such a huge number of subbranches on the system, we need to understand the performance impacts.

Any insight would be greatly appreciated.

Thanks,

ab

Adam Stoller

I'm not sure - but I think the only place where a huge number of sub-branches will affect performance is when you're trying to list them all in the GUI when navigating through the parent branch.

After that, I think the backing store handles storage of branches and sub-branches and directories and sub-directories fairly efficiently such that it shouldn't cause any significant performance issues on the back-end.

If each sub-branch is going to be "large" (in terms of contents stored within) - and thus making your backing store extremely large - you probably need to consider shelling out the $$'s for MultiStore licences so that you can break up the branches / backing store into mulitple backing stores -- this will make general maintainance (e.g. backups) significantly easier - though it may complicate branch-to-branch relationships if any exists between the branches that you split across backing store boundaries.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

chicka

Hi Guys,

I have faced similar kind of problems when the number of branches are increased drastically. In my project we have more number of branches, categories which you have mentioned.

Ultimately this will have severe impact in templating.cfg and Interwoven has recommended not to cross 1.5MB w.r.t this file. If it crosses more than the prescribed limit then it may lead to performance degradation like parsing of templating.cfg, servlet crashing issues.,

So request you to have a proper plan and gather fully documented requirement for your architecture.

Based on the above doc, please make an impact analysis also.

Regards,
Varun.K