nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

TS 6.1 weird performance issues

gzevin

We have upgraded one of the main boxes from 5.5.2 to 6.1.

now - the users could login to CC PRO with no issues, works fine.

When one tries to login to CC STD, it takes about 3-4-5 minutes before GUI repaints itself.
When I try this in Mozilla, I could see that it paints all but Work in Progress and Forms portlets pretty quickly, and then takes its time...

any ideas would be aprieciated. Of course, we have logged a support case.

yes, it's on Solaris

another question - to IWOV engineers/testers - have you given CC STD a good load test? It seems to me that out huge backing store and number of branches and templates causes this performance degradation

Find more posts tagged with

Comments

Adam Stoller

My guess (and that's all it is at this point) is any portlet which requires recursively (or iteratively) stat'ing files and/or directories in order to determine what to show and how to render it - will take considerably longer than those that operate on a higher level and just need to get a list.

While iwlistmod is fairly quick - if the intent is to distinguish those files that the current logged in user have modified from those that someone else has modified (in a potentially shared workarea) - I can see where the results from iwlistmod would then have to be parsed and each file entry returned would have to either be stat'ed or, more likely processed with another call - something like [from a Unix perspective]: iwfilestate -f script `iwlistmod areavpath | awk '{print "areavpath/"$2}'`which in turn would still have to be parsed to determine who holds the lock on each of the modified files and determine if that's the person who's currently logged in...

For the Forms portlet there's an issue of filtering all the possible Forms directories with the vpath-regex's in the templating.cfg file - I'm not sure of the exact processing order for this, but I could see this as something which might take time - especially since the default seems to be to show all possible forms in all available workareas rather than defaulting to a single workarea like the WIP portlet does.

You might try temporarily disabling / removing the Forms portlet alone and see if that provides a significant speed up in UI rendering...

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

gzevin

Adam,

yes, your thinking pattern just goes along ith ours...

I am going to switch off the Forms portlet to see whether it will ease the problem..

however, if the tests show that CC STD is slow by design, it would be a MAJOR problem - for us and for other companies ....

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

gzevin

another update -

it DOES look like the CC STD is not scalable for enterprise applications - it simply cannot handle the amount of bracnhes/workareas that we have got. I got a message from IWOV support that they also think that this was the case...

well... I hope someone could throw all the soldiers at IWOV to fix this, as I am afraid there will be a huge uproar of happy clients when they try to move to 6.1 with their real data...

I should admit that my current client has a pretty big structure.. but here we are talking about enterprise-level applications, aren't we?

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Adam Stoller

Interesting. Have they been able to put any rule-of-thumb numbers towards how many of what kinds of paramaeters cause performance degradation to begin? i.e. is it:

the number of form categories defined per branch in templating.cfg,
the total number of form categories defined in templating.cfg,
the number of form data-type defined per category,
the total number of form data-types defined,
the number of workareas per branch,
the total number of workareas in system,
the number of branches per archive,
total number of branches in system,
the number of archives,
etc.

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

cemman01

When we moved to TS5.5.2, the IW consultant then showed me a hardcopy of their load test with somewhat similar stats that you are asking for. But I doubt its for public viewing.

We have been having performance issues in the CC Pro interface and it seemed to coincide with large migrations of data we had done to setup an environment similar to Prod to allow clients to carry out realistic testing.

gzevin

Adam,

the issue is now escalated, and I hope it will reach head honchos in the Engineering.

I will keep you guys informed on how we are doing.
I had a 'webex' session with the support yesterday, so they had a chance to time logons. It took 2.5 minutes in average to get to CC STD after logging in.

for us it is essentially a show stopper. At least for CC STD, but we relied on it in some essential parts of new implementations.

we will probably go ahead with the move to 6.1 and will use the old WebdeskPro interface.

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

AKB

Even we are in the middle of the migration process from 5.5.2 to 6.1. Initially the performance was ok when there are no content. WIth the content same as that of 5.5.2..it is very slow. Infact the content that we have now is only 40% of what is being estimated at the end of the year.
CCPro works fine.
Time to open a case with Interwoven....

AKB

Just curious...if we remove the forms portlet..then how will users create new DCRs ?

gzevin

yes, please do open the case!

actually, CC PRO also is pretty miserable if you try to list modified files and some other operations on backing store.

I repeat again, that IWOV shouls start doing something about it, and quick or face customer wrath. Stop talking about successes of TS 6, it may be a good sales item now, but, as far as we are concerned, we are the major reference site for IWOV in Australia...

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

gzevin

We were talking about removal only for testing purposes.

Ok - now it looks like the Engineering has identified the backing store architecture as the culprit. I don't think it's the case.

I think servlets should use something of a lookup table-like entity that would be cached and augmented as required (say, triggered by 'new branch or new workarea or delete worakrea command), so no real-time lookups will be required!

Guys, watch this space.....more to come..

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

Everyone:

The expensive operation in TS6.1 is the identification of all
workareas available to an end-user. Particularly for servers
with a large number of branches, this operation can be slow.

This issue will be fixed with TS6.5. TS6.5 introduces a new
indexing services for workareas to speed up the workarea
listing module. TS6.5 will ship Oct. 28th and will be available
to any customer running 6.1 as a maintanence release. We
are finalizing development of TS6.5 this June, and are planning
our BETA release for limited customer audience this mid-August.

Kevin

Migrateduser

Do you believe it would be a reasonable course of action to continue with a planned upgrade but limit use to only professional view?

We are on a Solaris platform and in UAT, testing standard view with four branches and a handful of workareas we received reports of 30-60 seconds lag in fully loading views/pages.

In addition, we noticed several tasks created when a tester could not delete a file. These tasks cannot be transitioned or deleted. After a search of ‘on-line’ help, we still have not found anything relevant to the issue. It is my assumption that since this version is still new to us it is user error but unable to confirm that is the case.

boomer1

Hi Kevin:

Will this issue affect any other regular operations that end users perform that involve the backing store, particularly in CC Pro? We decided not to load test CCPro because our IWOV reps told us that it had been thoroughly load tested. Given your post, we are reconsidering that decision.

Thanks,

Michael

Senior Consultant
Principal Financial Group

Gregg Faus

Thought I'd chime in on our performance. I upgraded a couple of weeks ago and our users been very pleased. The CCSTD interface is very responsive and returns the page in less then a second. Here are some of our stats:
* 110 workareas - a third of which are shared with different groups, the others are just shared with one primary group
* 18 branches with templates
* 142 templates in total

This is a Win2k environment with 1GB of ram and dual 1.4Ghz processors. So not a powerhouse by all means.

My numbers aren't enterprise level, but I'm experiencing no problems whatsoever.

gzevin

as we don;t now HOW CC STD portlets collect their data, it would be hard to find a taxonomy that determines when performance starts to degratde.

as I mentioned - our implementation that has about 200 workareas and 35 branches takes around 3 minutes to load...

BTW, CC PRO also has shown degraded performance when doing 'Show Modified files'

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

gzevin

Ok - now I have some updates that I believe will affect ALL users of teamSite 6.1

IWOV came up with an idea of 'subscribing' users to their workareas, otherwise their product (CC STD) will not work for majority of customers who have a decent number of branches/workareas.

It will be a new screen, before starting up CC STD, which will let the users to subscribe - unlike the current functionality that lists all workareas/templating that a user can have access to. It will likely be a NEW system-wide config file that will let an administrator to subscribe the users, as I pointed out to IWOV that the whole idea of CC STD to have 'casual' users that are not even familiar with TteamSite and that don't need to be familiar.

IWOV also says they will do some changes in the indexing mechanism of the backing store, and we don't quite know yet whether this will have an impact in terms of the need to migrate data... This change will likely be in 6.5....

so, when you guys recieve messages from IWOV, urging you to upgratde to 6.1 and announcing the end of life of 5.5.2 in 1 year's time - I think you have some legitimate questions to ask.

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

iwovGraduate

The idea of subscribing seems to be similar to the way WorkSite displays the user's workspaces. I know very little about WorkSite though.

Can a user be subscribed to more than one workarea ? If so, then it really does not change much. Or does it ? It just gives an added level of filter for what the users see in the workarea.

gzevin

Can a user be subscribed to more than one workarea ? If so, then it really does not change much. Or does it ? It just gives an added level of filter for what the users see in the workarea.

yes, they can.

it won't change much in the end, IF we manage to do the filtering BEFORE a casual user logs in. However, subscription itself for casual users might pose a problem.

I don't have any technicals details now. I am just giving heads up, based on my conversations with IWOV senior managers and tech support on that.

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

This just sounds bad all over. Is it only me that feels like this is a hack to get around the problem rather than really designing a sensible solution? Maybe I'm not seeing what this will look like very clearly, but I'm thanking my lucky stars that most, if not all, of our users will be using CC Pro exclusively. Don't forget how I warned you all about 2 separate and distinct UIs. They will continue to develop further and further apart.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

gzevin

This is the problem that comes from previous versions of TeamSite - if you try to do ListModified in a workarea where there a lots of modified files - you might get the same performance....

but yes, you were dead right... and I wonder how come this prophet doesn't yet have his iPod?

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

Yeah we have probably more branches and workareas than you do and if it's like the List Modified wait time, well, we usually do List Modified before lunch and then when we get back an hour later we only have to wait a few minutes more. I don't like the way this "solution" sounds. It seems like more of a hack than really stepping back and solving the problem the right way.

Way to stir the pot, Greg. And the way those contractors are talking about Dev Licenses, I might wn the iPod by default. :0) Yeah...fat chance...

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

gzevin

yes, the solutions is UGLY - but guess what - IWOV is telling me that this solution is actually what some users from focus groups DID really want to see in the first place... too bad it did not get implemented initially.. now they get their wish come true!

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

Only "some" users? Usually when they do something and people ask why they say "many" or "most" people requested it. Ask them who those people were and suddenly they can't hear you. Now that they don't have Focus Groups they won't even have to worry about the witnesses that know who requested what.

A hack is a hack whether you try and justify it or not.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

gzevin

.. what is the name for 'some'? - a slew? I forgot....

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU