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. Scott Crouch selected this answer as the correct answer
Comments Sam, Thank you very much for your help on this topic. Glad to see we're not the only ones looking into things.
We're going to go ahead and start backing down the ChangeEvent expiration for work items to 5 days over the next several nights. It looks like the scrub task runs nightly, I would hate to overwhelm it with a big scrub. Did you end up changing the default expiration also?
We're on 4.0.1 so it sounds like the needed indexes are there?
We are working on a solution for #3 based on the information in comment 53, with a slight twist. It looks like we found an API com.ibm.team.feed.core.FeedManager that would allow us to change values from a java api. Still don't have 100% it's going to work, but giving it a try. I can share more if we get it working, just let me know.
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)..
1
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.
We also found that our DB had the default BUFFER_POOL was set way too low. We got a big improvement from the response times by fixing this.
cool.. did u use the Dropins folder to deploy the Eclipse plugin?
|
|||||||
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.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.