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)
performance metrics TS600 for folder size
catorarn
I have used the filecount.ipl script that is provided in knowledgebase article 50058 on one of our TeamSite servers. I note that the script is intended for pre 5.5 installations of TeamSite although another knowledgebase article suggests if entries started to reach 5,000 in any one directory performance issues could arise.
The script (in a pre 5.5 environment) warns at >500 entries and seriously warns at >1000 entries. What do you think the warn and serious levels should be in a post 5.5 environment?
Also we have 780 Staging Areas, 1549 Workareas of which 1549 Workareas are being used. Do you think this would impact on performance?
Find more posts tagged with
Comments
Adam Stoller
Is this DiscoveryChannel? If so, I think I'm the author of that script ;-)
The way the backing store worked changed significantly in 5.5[.2] such that - in the backing store - any given directory contains a maxium of (I believe) 512 file entries, thus if you had a directory in your branch that contained 1024 files, the backing store would have it broken up across [at least] 2 different directories - making the efficiency of listing the files in those directories fairly efficient - often more efficient than if you had the same number of entries in a local filesystem directory.
The impact of having so many file entries in a 5.5.2 (and higher) directory is in the GUI - where it tries to display all N files to the user. In 6.0 I believe this was dealt with by having the GUI pagenate file listings by default (something like 25 or 50 entries at a time) with links at the bottom to show the next N entries *or* show all of them (and pay the price of waiting for it to render).
I'm not sure about performance impact regarding number of workareas per branch (anyone have data for that?) - but I think that would really come into play if you were using something other than the default submit-lock model for the branch.
The other consideration (along these lines) for performance as I recall, is the number of locked entries at any given time - I believe this still imposes some impact - at least in the GUI - as it needs to determine which icon to display for each entry. I might be mis-remembering or mis-stating this though...
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com