Number of Files & Directories

I am trying to determine if we have set our TeamSite 6.1 cache high enough.

I see in the forums that the recommendation is 3x the number of files and directories in your largest branch... but I haven't been able to figure out an easy way to determine that number.

Surely there is some command line I can run somewhere, right?

Thanks for the help.

Find more posts tagged with

Comments

RajatChopra

I am trying to determine if we have set our TeamSite 6.1 cache high enough.

I see in the forums that the recommendation is 3x the number of files and directories in your largest branch... but I haven't been able to figure out an easy way to determine that number.

Surely there is some command line I can run somewhere, right?

Thanks for the help.

Do you have too many branches? You wouldn't need an EXACT number, just an approximation of the largest number on any given branch.

A simple way on either OS (Unix or Windows) would be to do a 'ls' (UNIX) or a 'dir' (WINDOWS) and get the total number of files and sizes. You can run the command on the mount point 'iwmnt' or 'Y:'.

ls -R does a recursive search of a directory. Might not work on all versions of the command

dir /s/a/p should probably help on Windows.

You can also output/pipe your result to a text file for in-depth analysis.

Adam Stoller

Do you have too many branches? You wouldn't need an EXACT number, just an approximation of the largest number on any given branch.

A simple way on either OS (Unix or Windows) would be to do a 'ls' (UNIX) or a 'dir' (WINDOWS) and get the total number of files and sizes. You can run the command on the mount point 'iwmnt' or 'Y:'.

ls -R does a recursive search of a directory. Might not work on all versions of the command

dir /s/a/p should probably help on Windows.

You can also output/pipe your result to a text file for in-depth analysis.

on Unix - find dir -type f | wc -l is better than using ls to get a count, and find . -type f -ls | awk '{printf $7"+"}' | awk '{printf $0"0\n"}' | bc will get you the total size (in bytes I believe).

You could also write a perl script to do this - and it would work on both platforms.

sixtrojans

To determine my optimum cache setting, I need to look at the largest branch, right?

In our implementation, it looks to me like we have 3 main branches and hundreds of subranches under one of those branches. I need to evaluate the total files -- including sub-branches -- in that one big branch, right?

(I'm really sorry for the noobish questions... lost our TeamSite admin and trying to figure out why our performance has been bumpy in the interim of finding a replacement).

sixtrojans

Okay, I just ran find dir -type f|wc -l on just one of my sub-branches (which itself has several sub branches) and came up with 2,326,434...

can that even be right? should I be excluding editions from this to determine optimum cache?

Adam Stoller

Okay, I just ran find dir -type f|wc -l on just one of my sub-branches (which itself has several sub branches) and came up with 2,326,434...

can that even be right? should I be excluding editions from this to determine optimum cache?

A sub-branch is a branch in it's own right - so calculations should be limited to the content of an individual branch - regardless of where that branch appears within your collection of branches.

The content you wish to count / size is generally the staging area of the branch - or one workarea (that's reasonably up-to-date) -- do not count every instance of every file in every edition and every workarea - that's a false number since TeamSite uses "virtual" copies of the same version of the same file in multiple areas.

chicka

It will be goood if you could refer TS admin document (not sure which version)
Basically we have a formula to calculate the cache value and it depends on the largest number of files in a directory.

RajatChopra

Basically we have a formula to calculate the cache value and it depends on the largest number of files in a directory.

I guess that's exactly what he is trying to do. Count the number of files in a branch.

The second question would be, what if he allocates more space? If he allocates 3.5 or 4 times the size of the largest branch, will that adversely affect the performance as well? Or is a factor of 3 just a thumb rule but not necessarily the only way out?

John742

the 3 times the largest branch is just a ballpark estimation. Some other things to take into account are:
RAM and VM footprint for iwserver
Workflow object thrash - iwstat -c (check available wftobjs and how often they get turned over). If I recall, once 90% of the total cache available used TS will turn some over that over. This will tell you how teamsite is caching cache objs relative to load. I believe there is a brief mention of this is the admin doc somewhere.
Also Workflow plays into this too, which really depends on wft design and use of workflow.
Keep in mind that too high of a setting could cause iwserver to die because of process limitations on a 32 bit os.
The biggest issue is making this deterimination is that there is no direct relationship between memory and vm use and a cache objects.
TS6.7.X has made advancements in performance around cached objects and content repositories, including memory monitor, and RAM and VM event triggers.
But the assumption is that you are seeing performance issues because of iwserver, but there are other things at work which could also play into what you are seeing: apache, tomcat, etc

Adam Stoller

the 3 times the largest branch is just a ballpark estimation. Some other things to take into account are:
RAM and VM footprint for iwserver
Workflow object thrash - iwstat -c (check available wftobjs and how often they get turned over). If I recall, once 90% of the total cache available used TS will turn some over that over. This will tell you how teamsite is caching cache objs relative to load. I believe there is a brief mention of this is the admin doc somewhere.
Also Workflow plays into this too, which really depends on wft design and use of workflow.
Keep in mind that too high of a setting could cause iwserver to die because of process limitations on a 32 bit os.
The biggest issue is making this deterimination is that there is no direct relationship between memory and vm use and a cache objects.
TS6.7.X has made advancements in performance around cached objects and content repositories, including memory monitor, and RAM and VM event triggers.
But the assumption is that you are seeing performance issues because of iwserver, but there are other things at work which could also play into what you are seeing: apache, tomcat, etc

To verify the cache thrashing - run iwstat -c in a loop while you're working ...