TeamTrack Performance Tuning
Discussion posted 3/6/08 by George Bonvanie
Hi All -- We've had TT in production for 2 solid years now, and are just now starting to perceive some slow-downs. I'm looking into any and all avenues to tuning.
2 web servers -- Win2K3 (don't seem to be taxed at all)
3 Primary tables -- ˜11000 items in each of two, and ˜400 rows in the third.
I wouldn't think that this volume of data would cause the system to slow down, but am working from a "don't know" position.
I'm planning to implement an archival strategy, but that will only get us so far.
Posted 1/10/2008 3:23 PM
Some say SQL is more native to TT and better performing. Is that an option for you? After system specs, license, etc are all verifiedI recommend trying to have support "black box" performance test your environment. I know that a couple of their support people out in Hillsboro, OR mentioned to me that this could be done now. Their are about a hundred other solutions I could suggest you throw at it but this might be the best use of your time.
Posted 1/12/2008 10:17 PM
Usually slowness is caused by downloading too much data to the browser. If you have particular forms that are slow, view the source of those forms and look for long lists. Make sure your systems user fields (like submitter, owner, last modifier, last state changer) are all set to read only. Other user fields or relational fields that have a large number of entries should be made searchable.
Posted 1/14/2008 9:30 AM
Thanks for the responses -- a couple more pieces of the puzzle:
1. We won't have MS SQL Server as an option.
2. The "slow"-ness I'm seeing is in some particular transitions, after clicking on "OK". These transitions are related to status checks between subtasks and their parent(s), and usually transitioning the other items if the statuses are aligned. I'm seeing REALLY slow processing of these in both cases (parent to child, and child to parent). In some cases, I've seen things that used to take 5 seconds ballon to 35+ seconds.
3. Generally speaking, "simple" transitions are still humming along fine.
4. My TS_CHANGES table has 1.5M rows, TS_ADMINCHANGES -- 1.2M. Could the sheer volume of data there make a difference?
Thanks for the suggestions so far! We're working on optimizing the Oracle DB at the moment.
[Updated on 1/14/2008 10:07 AM]
Posted 1/14/2008 10:07 AM
What exactly do you mean by status checks? Are there TeamScripts running? Of course, sheer volume will slow things down a little bit, but shouldn't be significant unless there are queries against large tables that are not taking advantage of a database index. Adding the appropriate database index will probably solve your problem, but the key is figuring out what query is taking a while.
Posted 1/14/2008 11:07 AM
There are a couple scripts in there, plus, at times, TeamTrack-ChangeMan integration attributes. Mostly, though, there are a series of binary fields such that I can use transition actions to do the following:
Run transition A (on the parent item) when all my sibling subtasks' field "B" are "C"
Frankly though, there really are not too many of those. The transitions with scripts don't seem to be much of an issue. That said, none of my scripts are very complicated (field value validation, etc.)
Posted 1/14/2008 12:15 PM
It only takes one ReadWithWhere to slow down a TeamScript. I think your best bet would be to have your DB Admin help you track down any long running queries that occur during the slow transitions.
Posted 1/14/2008 2:05 PM