TeamSite + Load Testing

Has anyone had to perform load testing against a TeamSite server? We are evaluating new hardware for our TeamSite server and I need to sign-off on the hardware selection. I am curious if anyone has undertaken an effort like this before and what methodologies were used. It would be great if Interwoven could provide a generic test suite to benchmark generic operations like many of the SPEC tests.

Unfortunately, I will not be able to run the same tests on our existing production TeamSite server. Some of the baseline stats may have to come from anecdotal evidence and or secret testing at midnight. For example, when we have more than X concurrent publish workflows, things start to slow down. Therefore, I must validate the new hardware can handle X*2 concurrent workflows. Some of the tests I was planning on running include:
o workflows (execution time and system load while increasing concurrent operations)
o file system operations (read/write/listing while increasing concurrent operations)
o User interaction with the GUI (I need to bribe my QA guy and hopefully get help with testing tools)

Also, what are some of the general bottlenecks that people experience with their TeamSite installations.

A few specifics:
OS: Solaris 10
Hardware: T2000 w/ 8 cores and 32 gigs RAM
TeamSite: 6.7.1
OpenDeploy: 6.1

~jed

Find more posts tagged with

Comments

nipper

Yea I have done similar, without the GUI tools (no GUI test). Basically I wrote a Perl script to traverse the directory structure in TS, reading the file names. Another that ran opening reading and writing the files (I overwrote the changes with a get latest after the fact). Another to read and rewrite the extend attributes.

I used time, but you could use Perls benchmark pm I suppose.

HTH

Andy

jed

I am currently in the middle of load testing. Initial results show TeamSite has limited scaling ability during write operations such as a submit, delete, create, touch, etc. During my tests, as I increase the number of concurrent write operations to *different* branches, write operations get dog slow.

Has anyone else experienced this?

During these tests:
o IO is not even close to saturated (from a device level)
o There are many mutex locks and system calls dring the operations. (Just guessing, but are all write requests round robined through one generic writer thread?) I might have to spend and afternoon with dtrace.

On a plus side, read operations do tend to scale gracefully. Once I complete my tests, I hope to publish the results.

As a teaser, a delete of ~2000 files takes:

Concurrent Deletes / Avg. Seconds to Complete Operation
1 / 20
2 / 22
3 / 33
4 / 62
5 / 88
6 / 162

Frederik

fascinating stuff. Thanks for sharing, Jed! Smiley Happy

dtheimer

I ran some network performance testing on TeamSite to understand why a User in India had a difference experience then someone in another country such as the UK. Simple terms - TeamSite does uses serial treading rather then multi-treading. The other two contributors to the issue was the size of the form and the pure distance from India to Illinois. Solution was to implement Cytrix.

This week we will be finishing up performance/stress testing using Rational testing tool on Reads, writes and searches. Want to know what the performance loss is when a second store is added and secondly, how many concurrent User Teamsite can support - hope to ramp up to 300-400.

Windows 2003

TS 6.7