It's all about the answers!

Ask a question

How to tune Jazz Feeds correctly?

Scott Crouch (48532326) | asked Mar 25 '13, 11:16 p.m.
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/

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

permanent link
sam detweiler (12.5k6195201) | answered Mar 26 '13, 8:34 a.m.
edited Mar 26 '13, 9:06 a.m.
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)
ChangeEvent Expiration by Item Type

ChangeEvent Default Expiration

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

Scott Crouch commented Mar 26 '13, 11:28 p.m.

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 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.  

sam detweiler commented Mar 27 '13, 12:01 a.m.

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.

Scott Crouch commented Apr 12 '13, 9:33 a.m.

 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. 

sam detweiler commented Apr 12 '13, 1:15 p.m. | edited Apr 12 '13, 1:16 p.m.

cool.. did u use the Dropins folder to deploy the Eclipse plugin?

One other answer

permanent link
Daniel Toczala (88211514) | answered Mar 26 '13, 8:24 a.m.
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

Register or to post 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.