Is it reasonable to take15-30 minutes to refresh Pending Changes view?
My client complained that it takes a long time to refresh the Pending Changes view in RTC 5.0.1 client. It usually takes 15-30 minutes. Is it reasonable? Any way to improve it?
Some streams can contain 200K files with size of 2GB in total. Anybody has similar experience in a real environment? I found this post and it seems that some users did have similar issues in the past. https://jazz.net/forum/questions/95786/can-we-disable-auto-refresh-in-pending-changes-view-when-login-rtc-repository |
One answer
Geoffrey Clemm (30.1k●3●30●35)
| answered Jan 09 '16, 6:17 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
If they are refreshing their Pending Changes view because they have updated some files directly on disk, instead of doing so via Eclipse, and they know in which file or folder the changes have been made, then it would be much faster to refresh just that file/folder, rather than refreshing the entire Pending Changes view.
Comments Thanks Geoffrey. It can be a good workaround for the client. I will ask them to give it a try.
I think that is NOT an acceptable work around. put the work on the customer..
Geoffrey Clemm
commented Jan 11 '16, 12:41 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Obviously it would be best if the command just ran faster with no user guidance, but until a way is discovered to make that happen, it is useful to know about potential ways to work around the problem. In particular, if you happen to know which file was changed (or what folder the changed files are under), then refreshing that file or folder will be significantly better than refreshing the entire Pending Changes view.
|
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.
Comments
Hi Donald,
I think its taking too much time, it is bit higher side.
1) Could you please check the Client Resources and also check is it same on the server for other clients as well.
2) Run the metronome and verify which one is getting more response time.
Regards,
Arun.
what is the network topology between the client and the server?
As I recall. Pending changes uses file compare, so it has to construct the last version at the server, then send it to the client to compare.. 1 file/change object at a time.
If your clients are connected over a WAN link, this could explain the issue.
long ago at my prior job, I proposed a squid server proxy caching model to get those calculated file versions near the client users, at LAN speeds. There is no tuning capability at the client to do any of this.
It appears that the hard word cannot be avoided then. I will work with the client to do a proper analysis and find out what's wrong.