How to tune Jazz Feeds correctly?
Accepted answer
1. change the event expiration (in the CCM server Advanced Properties) to something more reasonable.
60 days for workitem events is a LONG time, and they accumulate with each workitem change.
if you do software builds, change the build event expiration to something reasonable, we backed off to 2 days for those.
see this in the advanced properties (these are the defaults in 4.0.1)
| ChangeEvent Expiration by Item Type |
com.ibm.team.workitem.WorkItem:5184000
com.ibm.team.build.BuildResult:172800 |
|
| ChangeEvent Default Expiration |
1209600
|
|
In 4.0.3 M3, released 3/25, is a new feature to allow server centric control of the client polling process,
and some new code in the new Eclipse client to adjust the polling rate based on server info and actual results, as per the linked enhancement. (in either case u need to upgrade the clients to get this.. til IBM backports the client code to 3.x and 4.0.1 levels)..
2. If you are running 3.x there are also couple indexes you could add to the events database tables to reduce the time spent as well (we discovered this when one of our build processes had a bad side effect of jamming 100,000's of events in the table), clearly these tables were expected to be small.
these two table indexes were added to the 4.0.1 product, and there is some additional feed processing code change in 4.0.3 to reduce the cycles.
our jazzmon tracking of Feed response time shows a minimum of 6/10 seconds over a few months. but this is very sensitive to event volume. we hope that the new feed formatting code will reduce the overhead but are depending on the new reduced polling cycle..
3. we have also developed a tactical script that can be used to turn off the client side polling as part of our centralized admin service. See comment 53 of the linked enhancement for the logic of this process
we will have to run this multiple times, because whenever a user links to a new project area, the client creates feeds entries that begin polling immediately,, even for archived projects.. my Eclipse setup has 50 feed entries polling away.
Comments
Sam, Thank you very much for your help on this topic. Glad to see we're not the only ones looking into things.
note that to change the event age you have to restart the server each time.. really ugly in a production environment.. (we have 4 servers).. we did not change the default (for other feed pulls)..
note there is a special case, select a query, right click, select subscribe to feed query.. and it builds ANOTHER feed.. I think this one uses the default age time.
I'm interested in the api approach, but I'll be shocked if you find something..
looks like you could maybe GetChannels(), loop RemoveChannel( channel); and maybe you being logged in on each client.. but this will depend on Eclipse running.
on my machine I have 5 different Eclipse configurations. with no shared workspaces. each workspace has a different project list, and so a different feed list.
we've experienced another glitch the last couple weeks.. seems that adding entries to a build record causes RTC to create some unexpected event records,which drives up the data size, which causes an elongated processing time. at our 900,000 feed polls a day! this is over 9/second.. raising the elapsed time is not good.
Just wanted to update. We were able to write an eclipse client plugin that runs when is eclipse launches that disables some of the feeds that are created by default. This greatly reduced the number of calls made.
1 vote
cool.. did u use the Dropins folder to deploy the Eclipse plugin?
One other answer