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; } } }

Teamsite 6.7.1 SP2 Performance issues

System

Hi All,
We are on TS 6.7.1 SP2 on Windows 2003 OS for about last 6-8 months in production. The server specs is as per IW recommendation. The content store has grown over a period of 2 years from 12 GB to around 30 GB. Of late we have been noticing a lot of time outs and slow response time while using teamsite. The problem is very visible when we have more then 3-4 concurrent users accessing teamsite. We have around 15 DCT's that create DCRs in their respective folders. Couple of these folders have more then 3000 DCRs.

We have raised a support ticket but dropping this in here to see if any of the Guru's can shed some light on this issue.

Thanks in advance

Find more posts tagged with

Comments

Adam Stoller

Hi All,
We are on TS 6.7.1 SP2 on Windows 2003 OS for about last 6-8 months in production. The server specs is as per IW recommendation. The content store has grown over a period of 2 years from 12 GB to around 30 GB. Of late we have been noticing a lot of time outs and slow response time while using teamsite. The problem is very visible when we have more then 3-4 concurrent users accessing teamsite. We have around 15 DCT's that create DCRs in their respective folders. Couple of these folders have more then 3000 DCRs.

We have raised a support ticket but dropping this in here to see if any of the Guru's can shed some light on this issue.

Thanks in advance

Any time you have more than 500 entries in a folder, and certainly more than 1000 - you increase the potential for performance degradation for any process that has to search through that folder. The TS server itself does not have problems with this as the actual backing store uses it's own mechanism to organize the files there (I believe it limits each folder in the backing store to having 255 files) - but any custom code that has to sift through those folder from the file system interface or any GUI code that has to render that many files will tend to suffer because of it.

I suggest trying the following things:

It will take some effort to do this - not only to get the existing content structured, but to put in place functionality to automate the creation and maintenance of such structure so that you don't run into the same problem a year or two from now.

CRB

there is no sp2 for 671, do you meant 672 sp2?
was this an upgrade? from what version?
any hanging workflows?
are the 3000+ DCRs in the same folder? or structured?

cool_rash

Please recycle your log files.

Migrateduser

[QUOTE=ghoti]
I suggest trying the following things:

My bad - we are on 6.7.1 SP1 Patch1 - New build from 6.7.1 not a migrated store.We ran the workflow utility to look for stale job/wf's but came back clean.

Migrateduser

Please recycle your log files.

one of the very first things we tried..

30-60-90.rptdesign

Adam Stoller

You should probably open a support case and see if they can assist you in tracking down the source of the performance issue(s)

Migrateduser

You should probably open a support case and see if they can assist you in tracking down the source of the performance issue(s)

Yes we have this as a Sev 1 ticket with support. IW is trying on their end to zero in on the issue, but its been almost 3 days and we are no where...

MultiSeries.rptdesign

test.txt

CRB

do you know if the disk was raid 1+0 configured ?
since teamsite makes a lot of write operations, if your disk wasn't configured properly you will see slowness in teamsite due to the time it takes for the OS to complete all the write operations. your system admin can check for this issue.

Jamik

Couple of these folders have more then 3000 DCRs.

I'm betting this is the issue. To verify this, if you have a dev box available, try bringing your backing store down to your dev box and recreate the slowness on Dev (can be hard to do since it's two different environments). When you've replicated the slowness in dev then bring those directories on dev down to a more manageable file count and see if you still have slowness issues.

Migrateduser

I'm betting this is the issue. To verify this, if you have a dev box available, try bringing your backing store down to your dev box and recreate the slowness on Dev (can be hard to do since it's two different environments). When you've replicated the slowness in dev then bring those directories on dev down to a more manageable file count and see if you still have slowness issues.

I belive we will be heading towards this test pretty soon.

Migrateduser

Did this test, brought down the production store to the dev server, broke out the folder into less then 1000 files in each folder, activated the 3GB switch as per support recommendation. Also upgraded the Patch to Patch 7 as IW mentioned it has cumulative performance fixes addressed in this patch. Cleaned up all the Zombie files and work flow, but still with 6+ conncurrent users on the box, we see response time in upward of 40 seconds.

civ3

Did this test, brought down the production store to the dev server, broke out the folder into less then 1000 files in each folder, activated the 3GB switch as per support recommendation. Also upgraded the Patch to Patch 7 as IW mentioned it has cumulative performance fixes addressed in this patch. Cleaned up all the Zombie files and work flow, but still with 6+ conncurrent users on the box, we see response time in upward of 40 seconds.

You still have this issue after more than half a year. I notice you mentioned your 6.7.1 was a new build but content store is not migrated. Was the content store copied from old installation? What version is it? Did IW support suggest to migrate the content store?

I am interested to know what causes the issue. Please keep us updated.

Best regards,
civ3.