Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
CC Standard Performance and Branching Strategy
AKB
TeamSite 6.1 with service pack 1
OS: Windows 2003 Server.
Hi,
My present client has implemented TeamSite such that all the websites are under one workarea. Each website is a sub folder under the workarea.
We just moved all the directories and couple of files from 5.5.2 to 6.1 for testing. When a user logs in to the CC Stsandard UI, it takes around 60-90 seconds to log on with around 10 files but lots of directories. SUPPORT CASE WAS ALREADY OPENED AND INTERWOVEN ACKNOWLEDGED THAT THE ISSUE IS WITH THE BACKING STORE PLUS.....
At the same time we do see two options from our side to improve performance:
1) Instead of having only one branch and one workarea, go for combinations of branches and workareas. All huge sites will be in a branch and all small related sites will be in a branch with each website being a workarea under that branch.We tried this approach with test scenario and the performance improved.
2)The second option was to change the default setting of Work in Progress and Workarea browse portlets(so called) to check the permissions starting from the sub folder level instead of the workarea level. I do not know whether Interwoven will support this functionality and also will it be compatible with the Architectural changes and UI changes Interwoven is doing with each release. With this approach we can still maintain our present branching strategy (single branch/single workarea).With this approach when a user logs on only those folders/websites under the workarea that the user has permissons will be parsed during the user log to find the modified files(instead of parsing all the websites). We think the performance will be better.Wanted to know other consultants input on this as which approach will be better.
I am inclined towards the first option.
Thanks in advance
Find more posts tagged with
Comments
lhdavis
I would lean towards option 1 as well (trying to avoid the architectural changes to support option 2 which may or may not work in future releases).
However, I would probably not have all the "small related sites will be in a branch with each website being a workarea under that branch". Unless you are automating the "Get Latest" functionality, you could have one site overwrite the content for another site if they are all in different workareas under the same branch. I've seen it happen many times.
I would suggest putting any common files that are shared among the related sites at the top level of the so-called "Related" branch but assign each small site their own subbranch, under the "Related" parent branch. Without looking at your content or site taxonomy, that's a shot in a dark but it seems to be a common thought to not have separate sites share the same branch but reside in different workareas.
Just my $0.02. Good luck!
Luke Davis
Open Technology Group, Inc.
luke.davis@med.va.gov
bboyle
we use the sub branch with single workarea structure (TS552) and it seems to be holding together so far.
common files are likewise managed in a sub branch (Web Components).
Approved sub-branch content is promoted (iwupdate) to an integration workarea on the parent branch (from the staging area on the sub-branches). It is submitted and deployed from this parent branch (rather than deploy from all sub branches).
Previews are supported across all sub branches by using a failover proxy mapping that shows content from the parent branch staging area.
Just some notes that might help.
Good luck with it!
gzevin
weel, as you could probably see, I had reported this issue some time ago, and IWOV is doing serious changes.
so far I heard of the only successfull improvent of performance - this happens only if you totally disable the 'work in progress' portlet
Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU
AKB
Infact we opened a case around 2 months back on this. As I said they reported that they will be able to fix the same only in 6.5. The case is still open. This post was to make changes from ourside to improve performance a bit.
gzevin
yes, I've just checked, I logged the case sometime on 16-18 of May.
I dunno what they are telling you, but we are expecting the fix for CCS not in 6.5 (which will be a delay till 6.5.1), but ASAP. it was meant to happen by the end of July.
Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU
AKB
However, I would probably not have all the "small related sites will be in a branch with each website being a workarea under that branch". Unless you are automating the "Get Latest" functionality, you could have one site overwrite the content for another site if they are all in different workareas under the same branch. I've seen it happen many times.
-------------------------------------------------------
Well if Interwoven starts charging based on number of branches then I think it makes sense to have smaller related business units to be workareas. The content will be totally different in each workarea starting with different folder name thus there is no question of files being overwritten and also there is no point in using GetLatest functrionality for that branch.
ApprovalCodeExample.zip
Adam Stoller
That's completely the wrong model and essentially a mis-use of the system - guaranteed to give you no end of troubles down the road. If you don't like the per-branch charges (which I think are ludicrous) then get a different CMS system rather than mis-using the one you either have or are thinking of purchasing.
I can't remember where this per-branch charge issue started - do you know the source of the statement and/or the facts behind it (if any)?
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
lhdavis
I have to concur with ghoti on this one.
Let me just say that if you go with this model and a user ever does to a "Get Latest" with Overwrite selected (don't think they won't, stranger things have happened), there goes your separate folder for that particular site in the workarea. And your STAGING area could end up a mess. On one of my earlier projects with TeamSite we tried this and it failed miserably. Users continued to forget to do a "Get Latest" on their workarea (we didn't automate it back then) and would overwrite other websites content.
If you only have one webmaster who is fully trained on the product and will never do this, great. If you hide the "Get Latest" functionality from all of your Editor's, great. But you are putting yourself at risk with this model and, if things did get overwritten, it will be a pain for your TeamSite Administrator to restore the content to all of your different workareas based on what is in the STAGING area.
Now if they are related sites and you have no problem with everyone seeing each others content, by all means use one workarea. But that means that user A could modify content for a site that they are not supposed to. But I would not recommend multiple workarea within a single branch, each one for different sties.
I just think if you are going to use the tool as is intended, you use separate branches/subbranches for separate sites. Again, just my $0.02 (maybe $0.03 now). Good luck!
Luke Davis
Open Technology Group, Inc.
luke.davis@med.va.gov
AKB
That's completely the wrong model and essentially a mis-use of the system - guaranteed to give you no end of troubles down the road.
Troubles like ?
Definitely the first option will be having a seperate branch for each website (that is what we will end up doing, I think). Just for awareness purpose Wanted to discussion the troubles of the following option:
MyIntranet (BRANCH)
WomenNetworksWA (WORKAREA)
WomenNetworks (folder under workarea WomenNetworksWA )
Images (subfolder under WomenNetworks)
folderB (subfolder under WomenNetworks)
folderC (subfolder under WomenNetworks)
RiskManagementWA (WORKAREA)
RiskManagement (folder under workarea RiskManagementWA )
Images (subfolder under RiskManagement )
folderB (subfolder under RiskManagement )
folderC (subfolder under RiskManagement )
STAGING
womenNetworks
Images (subfolder under womenNetworks)
folderB (subfolder under womenNetworks)
folderC (subfolder under womenNetworks)
RiskManagement
Images (subfolder under RiskManagement )
folderE (subfolder under RiskManagement )
folderF(subfolder under RiskManagement )
what risks will be involved. WomenNetworks and RiskManagement are sites having between 10-30 pages. Content is not shared.
The document that I have says corporate edition (max branches 10). I do not know whether there is enterprise edition that has unlimited branches. Once it is confirmed that enterprise edition(if it is different from corporate eidtion) gives unlimited branches then there is no question of having multiple workareas. At the same time wanted to discuss the drawbacks of the above option ....
I agree we cannot have a snapshot of the website at any particular time. But then the content that is supplied is only xml to the portal server, and having website snapshot is not a requirement for such small sites.
We do not need getLatest also and content center Standard does not have this feature anyhow.
Adam Stoller
The underlying basic concept of TeamSite is that workareas are a virtualization of the entire staging area - as such - you are trying to ignore that concept by suggesting that you have different structures in each workarea for a given branch. There are any number of ways that a Get Latest / iwupdate can be performed - and since you cannot restrict people from using CCP (where Get Latest *is* available) - you are asking for trouble trying to follow the model you are suggesting.
What trouble? - well for starters if someone in the WomenNetworksWA creates a directory called RiskManagement (for whatever reason they decide) - and submit it - it will be in direct conflict with any content that exists in the RiskManagement folder of the RiskManagementWA - potentially deleting *all* the content there (available in editions) with the other content.
Sure - it's recoverable - but it will tend to cause a great deal of confusion, potentially screw up the actual web site, and more than likely will take a considerable amount of time to fully recover from it.
Is it likely to happen? Perhaps not. Is it possible to happen? Absolutely.
If you want to restrict who has access to which folders in a workarea - do so at the file system level - such that all workareas will see the top-level folders "WomenNetworks" and "RiskManagement" - but the group-for-sharing of the WomeNetworksWA will only have file system access to the "WomenNetworks" directory and the group-for-sharing of the RiskManagementWA will only have access to the "RiskManagement" directory -- you'll need to set up your submit.cfg file appropriately to make sure these access rights are correctly applied whenever a submit operation occurs.
Everyone will see all the top-level folders, but through the file system access rights placed on those folders, individuals who have access to only a single workarea will only be able to see / modify content within that single directory structure associated with their workarea. (you may have to play around with the iwwebd configuration though, as I seem to recall that by default it won't restrict access within the browser UI - I could be wrong about that though).
There are probably other issues that you would need to resolve if you tried keeping the workareas looking distinctly different - but the above is an example of such a problem (and yes, I've seen this in the field when someone tried to do what you were describing - it causes lots of headaches because it's the "wrong" way to use the tool)
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
Migrateduser
I don't understand why you would need submit.cfg or multiple workareas for this - can't you just use NTFS permissions on folders and inheritence in a single workarea? The only thing that would worry me in a single branch/workarea approach is having users create folders at the root level, but that can probably be avoided through permissioning?
AKB
The issues that you have raised could be solved by having custom code: example controlling the creation of folders (as autogeneration of the content is a requirement and the folder stucture of the DCR and the generated pages needs to be same) Folders will be created only after checking it under the staging area....
permissions: Do it at the folder level using OS.
etc etc etc
but....
Apart from the issues that you have raised, other issues will be like:
In Staging area, the DCRs of each website will be merged..leading to confusion there..
The bottomline is: the amout of money that will be spent in maintaining this way ( each website having its own workara) will be more than money if any charged for having additional branches.
