Teamsite Optimization and Performance

IMHO, you are very short on memory.

My freaking laptop has 8 GB, but what is the most memory for 2203 ? How did you get an OS 200 years in advance ? :-)

Also, I thought RAID 5 was slow, but I have not checked the manual to see,

SAN would certainly be a good idea.

First things first - performance of...?

My assumption is UI, but if you can be more specific then there's a better chance of focusing in on the underlying issue.
Perhaps for example it's from badly designed/implemented forms, or badly performing SitePublisher components rather than environmental.

70 concurrent users is high for TeamSite and you may want to consider tweeking a few variables to cope.

iw.cfg
Make sure your fsthreadcount is twice that of your number of cores
Try increasing the cache setting (default 30000, consider 200000 and review)

Servletd (Tomcat)
Change the RAM allocation (I don't have the details to hand, but there are some Java VM params which can be updated).

Check to make sure that if it's UI, that it's not related to a background network usage issue.
A really handy trick is to use iw.ping to give you a round-trip timing for requests into the UI. Use:
http://servername/iw-cc/command/iw.ping

I'd suggest using this from different locations, at different times of the day including on the same LAN as the server / on the server itself, and compare results.
Can you detect trends?

Make sure to keep an eye on core TeamSite usage using the command line:
iwstat -c

It's good to run it regularly for a period of time, and then review the results.

Check to see how much / many operations are taking place.
You can also use the output from iwstat -c to see what impact your changes to the cache setting in iw.cfg have made.

Consider if you have any intensive "back ground" tasks - workflow tasks perhaps which are trawling the content store / major moves of content in the store etc.
If you have activities which might be performance impacting, consider restricting their use / scheduling to quieter times on the server.

SAN vs directly attached storage: I don't think you are going to see much difference in the way of performance, if anything directly attached may be quicker.
No doubt there's someone on the forum who's done the maths, but from an architectural point of view SAN is normally considered for helping with backups and allowing for failover rather than a performance improver.

These are just a few pointers - performance troubleshooting is always a challenge, but perhaps that's given something for you to think about.

Regards

I am mainly talking about the Backing store Performance. This is getting slow and also we do receive those errors

Application popup: Windows - Delayed Write Failed

We have checked if The Hard Disk were sick/damage but there is no issues with them.

Thanks for your help

Changing the iw.cfg cache setting may help as it will give TeamSite more RAM to buffer content.

I would still recommend using iwstat to see what TeamSite is actually doing when you are experiencing the issues.
It's a good idea to run it say every 30 seconds for a period of time just to get a feel for the activity on the server, and to see what the cache is doing.
For example, it might reveal that an inconsequential action through the UI results in a lot of background TeamSite activity.

Not that it's going to help necessarily with performance, but it would be worth using iwfsck and iwfsshrink

iwfsck to check for logical errors in the content store
iwfsshrink to remove orphaned files (should be run on a regular basis as part of general housekeeping)

I never considered it before, but it might also be worth defragmenting the hard disk the store is on (not the Y drive, but where the raw data is).

If nothing really seems to help, then you could move the store to another disk partition (directly attached or SAN) and see if that makes any appreciable difference.

Regards,

Adam Stoller

...
iwfsshrink to remove orphaned files (should be run on a regular basis as part of general housekeeping)

Just a slight correction here - iwfsshrink does not remove "orphaned" files - it removes "dupliacate" files which are [generally] the result of either (a) very old submit activities [like pre-5.5.2 TS] or, and more likely, (b) running iwconvert.

In this case, the term "duplicate" means two versions of the exact same file (e.g.: /default/main/foo/.../bar) that each refer to different sets of metadata (the reason there were two versions of the file) - the backing store was changed around the time of 5.5.2 (if memory serves correctly) so that the internal code that tracked versions could contain multiple references to the same physical file data and associate it with different versions of the metadata data - thus avoiding the duplication of the file data in the backing store.

For some [unknown] reason - when submit activities are replayed through iwmigrate- this efficiency does not happen and thus you end up with bloated backing stores that require iwfsshrink to fix them.

As such - running the command after an iwmigrate and/or quarterly [at most] is generally sufficient.

(I don't remember, but convert might have the same flaw - so running iwfsshrink after iwconvert is probably also recommended - though you shouldn't have to do that very frequently)

We run TS on a 8 Core 2 GHZ Intel Xeon(R), 3326 MB Memory, Win 2203 SP2

I still say this amount of memory is way too low. You will not be able to push the cache settings up too high with only 3 GB.

Try turning off MT to see if that improves performance. Sometimes people push that off on another system.

Do you have search installed on this server ?

Well, yes, exactly: I entirely agree with your description of the functionality of iwfsshrink; it does hunt out and eradicate duplicates.

I also (mis?)understood that it removes files that are no longer referenced in any area (Staging, Edition etc.), and was therefore a good thing to use following Edition removal.

Perhaps the more important point to note is that it's a good thing to run iwfsshrink, and that if you schedule a quarterly run of iwfsshrink then you can forget about the finer details.

Regards,

I have changed the cache to 200 000
also add the fs_threadcount=16
and the memory usage is at 2.7 gig right now

BTW I do the iwfsshrink once per 3 month.

thanks

BTW I do the iwfsshrink once per 3 month.

That's the recommended frequency.

If it's never been run then expect a relatively large saving first time around, with a smaller return on subsequent runs.

Regards,

I have changed the cache to 200 000
also add the fs_threadcount=16
and the memory usage is at 2.7 gig right now

If you are using 2.7 GB of 3.3 available I can imagine you get memory starved at times (assuming that is not a peak).

Any idea if you can get more RAM ?

Also depends on what flavor of 03 you use. Per Microsoft:

Here's a list of how much RAM the various Windows versions and editions support (as of May 2010):

Windows Server 2003 Web Edition: 2 GB
Windows Server 2003 Standard Edition: 4 GB
Windows Server 2003 Enterprise Edition: 32 GB
Windows Server 2003 Datacenter Edition: 64 GB

We going to add 4 gig tomorow
We do have EE so it is not an issue.
70 concurent is it really that high for Teamsite??????

Truly concurrent, probably. Certainly not the largest, but not a small implementation (which is 4 GB)