CC/CQ Connector performance
Hi all. At RSDC, the Jazz team demoed the CC connector and discussed the rather poor performance at that time, but that they had a strategy for improving it. Can someone give us a status update. If we have a customer's project with, say, 4G of data in a few CC VOBs and 12K records in CQ, could a small, agile team on that project pilot Jazz and use the connectors to sync with the rest of the project? Is that something we would recommend yet? And I hate to put anyone on the spot, but if not now, any ideas when?
Thanks.
Thanks.
One answer
The performance for the M3 CC Connectors has not significantly changed
since RSDC. So the primary purpose of the M3 release is to get feedback
on the proposed usage model. But we are very interested in getting that
feedback, so let me know if we can be of assistance for you to try it out.
The main performance item we are currently working on (i.e., in M4) is
allowing the "sync" operation to be performed as a build job (since it
can take minutes to hours, depending on how much you are sync'ing).
Note that the key metric for CC Connectors is how many files have
changed since the last sync. In particular, the cost is proportional to:
- for each UCM component that contains a sync root
- a few cleartool describe commands
- a mkbl command
- a diffbl command
- for each entry in the diffbl command
- a few cleartool describe commands
- for each changed file in TeamConcert
- a few cleartool describe commands
- a checkout command
- a file copy
- a checkin command
- for each changed directory/folder in TeamConcert
- a few cleartool describe commands
- a checkout command
- the necessary number of cleartool mv commands
- a checkin command
Also note that with ClearCase Connectors, you don't sync over a whole
stream, but rather the specific set of individual IDE projects that you
will be working on in TeamConcert.
So the main performance question isn't so much how many gigabytes of
data, but rather how many files are being sync'ed over.
Cheers,
Geoff
since RSDC. So the primary purpose of the M3 release is to get feedback
on the proposed usage model. But we are very interested in getting that
feedback, so let me know if we can be of assistance for you to try it out.
The main performance item we are currently working on (i.e., in M4) is
allowing the "sync" operation to be performed as a build job (since it
can take minutes to hours, depending on how much you are sync'ing).
Note that the key metric for CC Connectors is how many files have
changed since the last sync. In particular, the cost is proportional to:
- for each UCM component that contains a sync root
- a few cleartool describe commands
- a mkbl command
- a diffbl command
- for each entry in the diffbl command
- a few cleartool describe commands
- for each changed file in TeamConcert
- a few cleartool describe commands
- a checkout command
- a file copy
- a checkin command
- for each changed directory/folder in TeamConcert
- a few cleartool describe commands
- a checkout command
- the necessary number of cleartool mv commands
- a checkin command
Also note that with ClearCase Connectors, you don't sync over a whole
stream, but rather the specific set of individual IDE projects that you
will be working on in TeamConcert.
So the main performance question isn't so much how many gigabytes of
data, but rather how many files are being sync'ed over.
Cheers,
Geoff