How to tune Jazz Feeds correctly?
We're seeing a lot of calls to Feeds and are frequently taking a long time to complete. Are there any suggestions on tuning the feeds settings for better performance?
I can also tell that the eclipse client creates a lot of feeds automatically for users, but most of our users aren't even using these feeds. Is there any way to prevent these feeds from being created automatically?
Also, there's a specific call to GET /ccm/service/com.ibm.team.repository.common.internal.IFeedService/ccm/service/com.ibm.team.repository.common.internal.IFeedService?itemType=WorkItem&user=_____&maxResults=1000&since=2013-03-22T14:03:00Z
This call seems to take a long time very frequently. As far as we can tell it's from the My Work Item Changes widget on the jts personal dashboard. Any ideas what we could do about this?
Accepted answer
well, there are a number of things you can do today..
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)
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.
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
1 vote
One other answer
We've noticed this too. There is no way to tune this at the present time, although we have plans to implement something so you DO have the ability to tune these feeds. See Enhancement 239753 for more information.