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 Performance Issue

chiksur

Hi All,
During DCR submissions sometimes the time it takes to submit the dcr to the staging area is around 8 minutes.This kind of latency is increasing the performance spike on the iwserver service.
Do any of ou have any idea why a simple submit task in the workflow would directly spike the performance for the iwserver on the whole.

Find more posts tagged with

Comments

motlnt

Hi All,
During DCR submissions sometimes the time it takes to submit the dcr to the staging area is around 8 minutes.This kind of latency is increasing the performance spike on the iwserver service.
Do any of ou have any idea why a simple submit task in the workflow would directly spike the performance for the iwserver on the whole.

can you detail your env. here?

MukeshYadav

Hi All,
During DCR submissions sometimes the time it takes to submit the dcr to the staging area is around 8 minutes.This kind of latency is increasing the performance spike on the iwserver service.
Do any of ou have any idea why a simple submit task in the workflow would directly spike the performance for the iwserver on the whole.

Is your store local or this mounted thru NFS? If your store is not local, hosted on different server and is mounted thru NFS, it may take that much time depending on the network performance.

Adam Stoller

Also - out of curiosity - how many DCRs exist in the data/ directory?

kshitiz

Hi All,
During DCR submissions sometimes the time it takes to submit the dcr to the staging area is around 8 minutes.This kind of latency is increasing the performance spike on the iwserver service.
Do any of ou have any idea why a simple submit task in the workflow would directly spike the performance for the iwserver on the whole.

How are you submitting your DCR? Is it through workflow, command line tool, some script etc.
If possible post the code as well.

chiksur

Max Number of DCR : In the Data Folder are not more then 100.
DCR Submission : Through Workflows.We do call certain CLT's within the
perl ipl files which are called from the workflows.
Store : Local. E:\iw-store

Search : this is the only thing which we do differently.

Index are run on the production teamsite box and search is installed on a replicaserver and the index collections are stored there.Search on production teamsite uses the stored indixes from the replica server.

I will post the snapshot of the workflow code when I get to the office

Adam Stoller

Ideally, you should have your code contain all sorts of diagnostic output via something like Log::Log4perl such that there are timestamps with each diagnostic message. Using this model you can then put diagnostic messages before / after each CLT call, etc. and use the output to determine where/when the latency is actually occurring and on which file, etc.

Once you have that information, try to reproduce it to determine if it might be file-specific. If not, look for other things that might be happening (processes, network bandwidth, etc.)

chiksur

We have the log4j Module in place and all the logging has been implemented which track everything in our temp logs.we did enable the module to check to see if there is any latency involved but everything looks fine.

The CPU keeps Jumping inbetween 50% to 90%.

Some Interesting things which we noticed as a part of the "Teamsite Server Statics" are listed below.these stats are from 6/20/09 12:52:14 PM till today

Do you have any idea what CFILE_LOOKUP_svc ,CFILE_GETATTR_svc services do as there numbers look off the Charts

TeamSite Server Statistics [ since 6/20/09 12:52:14 PM ]

test
Store Operation Invocations Avg Duration Min Duration Max Duration
default CFILE_LOOKUP_svc 167,646,101 0.000s 0.000s 18.906s
default CFILE_GETATTR_svc 79,239,239 0.000s 0.000s 19.688s
default FindFSEByID 28,327,117 0.000s 0.000s 10.797s
default IterateAllEditionsByIDBatch 27,943,846 0.023s 0.000s 40.204s
default trp__IsPermitted 27,799,990 0.000s 0.000s 1.360s
default ReadFile 25,969,189 0.000s 0.000s 16.750s
default CFILE_ACCESS_svc 22,802,219 0.000s 0.000s 8.890s
default CFILE_READDIR_svc 12,964,444 0.007s 0.000s 16.688s
default CFILE_GETPAGE_svc 9,426,092 0.004s 0.000s 15.875s
default CFILE_SETATTR_svc 5,569,980 0.000s 0.000s 12.422s
ParseVersionPath 2,725,183 0.000s 0.000s 0.297s
default CFILE_GETSECURITY_svc 2,704,015 0.000s 0.000s 1.250s
default LookupObjids 2,425,004 0.004s 0.000s 26.345s
default IterateExtAttr 1,522,647 0.000s 0.000s 0.234s
default FindFSEByName 1,474,068 0.000s 0.000s 15.266s
GetQueryStatus 1,436,040 0.001s 0.000s 18.251s
GetGlobalRolesFromArchive 1,229,082 0.000s 0.000s 36.876s
default IterateSubmitEntry 973,169 0.000s 0.000s 0.141s
default GetPath 962,208 0.001s 0.000s 13.719s
default IterateSubmitEvent 814,982 0.001s 0.000s 0.687s
default FindBranchByID 752,661 0.000s 0.000s 40.126s
workflow trp__GetTaskAndJobOwner 665,495 0.000s 0.000s 8.891s
default FindBranchByName 631,920 0.000s 0.000s 0.297s
default LookUpFSEObjids 527,502 0.009s 0.000s 0.922s
default GetOpenApiFSEInfo 488,196 0.005s 0.000s 12.359s
default FindEditionByID 462,088 0.000s 0.000s 7.766s
default FindWorkareaByID 415,345 0.001s 0.000s 5.828s
GetOperationInfo 398,576 0.000s 0.000s 0.484s
default LookupEA 395,072 0.000s 0.000s 10.719s
workflow IsTaskOrJobOwner 386,802 0.000s 0.000s 7.906s
default GetRelinkedFSE 336,756 0.002s 0.000s 3.500s
default FindAreaByID 256,656 0.000s 0.000s 0.453s
workflow GetWFObject 239,859 0.018s 0.000s 57.298s
default FindWorkareaByName 210,434 0.003s 0.000s 31.157s
DiscardQuery 208,368 0.002s 0.000s 8.860s
FlushOutEntity 207,700 0.058s 0.015s 9.969s
default LookupVpathFSEInfo 205,805 0.018s 0.000s 13.141s

KTReddy

Any Progress on this issue? We are facing similar issue. Hope solution for this issue can guide us in right direction and save some time. We have TS 6.5SP3 on Solaris.

chiksur

our issue got resolved after we cleared up the IIS Cache.Please follow the TS Admin documentation and it might help you.