poor CC connector performance
Hi All,
just share with you, here is the performance test result for CC connector in our environment,
1) CC to RTC: about 20,000 files to sync, took about one day to do that (it took about half hour to import these 20,000 files from file system into the same RTC server with RTC client).
2) RTC to CC: about 20,000 files to sync, took more than one day (it took about 2 hour to import these 20,000 files from file system into the same CC server with clearfsimport).
the performance is not acceptable to us, so if you are thinking about using CC connector to do something, and you do have more than 20,000 files in your project, please test it first, and if you have a better performance with CC connector, please kindly let us know, maybe there are some tips ....
Regards,
Makson
just share with you, here is the performance test result for CC connector in our environment,
1) CC to RTC: about 20,000 files to sync, took about one day to do that (it took about half hour to import these 20,000 files from file system into the same RTC server with RTC client).
2) RTC to CC: about 20,000 files to sync, took more than one day (it took about 2 hour to import these 20,000 files from file system into the same CC server with clearfsimport).
the performance is not acceptable to us, so if you are thinking about using CC connector to do something, and you do have more than 20,000 files in your project, please test it first, and if you have a better performance with CC connector, please kindly let us know, maybe there are some tips ....
Regards,
Makson
18 answers
Hi Geoff,
if you don't think you have any performance issues about your product,
then IBM should have the responsibility to tell customer that this product is suitable for the case you metioned only.
why i feel CC Connector applies to our case? good question, because IBM told us about that.
Regards,
Makson
if you don't think you have any performance issues about your product,
then IBM should have the responsibility to tell customer that this product is suitable for the case you metioned only.
why i feel CC Connector applies to our case? good question, because IBM told us about that.
Regards,
Makson
I would try to make the discussion move forward to solution and check if CC connector can match the requirement in the next release.
For Lee's requirement, the two teams in the different side of CC Connector belong to two companies. In stead of frequently sync, enough testing before sync is the BEST PRACTICE to them. That's why changes will be accumulated in stead of immediately sync. I think even in the same company, each team should well test their code before deliver it to integration.
Currently sync 1000 file from RTC to CC takes about 1 hours in the current version. If Lee can get the average number of files for incremental sync and the acceptable time in real case (eg 3000 files in 1 hours), we can have breakthrough. It's more meaningful than discuss what's the best practice I think.
For Lee's requirement, the two teams in the different side of CC Connector belong to two companies. In stead of frequently sync, enough testing before sync is the BEST PRACTICE to them. That's why changes will be accumulated in stead of immediately sync. I think even in the same company, each team should well test their code before deliver it to integration.
Currently sync 1000 file from RTC to CC takes about 1 hours in the current version. If Lee can get the average number of files for incremental sync and the acceptable time in real case (eg 3000 files in 1 hours), we can have breakthrough. It's more meaningful than discuss what's the best practice I think.
Let's separate out a few related but distinct issues.
Are there any performance issues with the CC Synchronizer that are
currently being worked on?
Yes. Please see work item 114744: "Importer doesn't scale very well in
the initial treesize dimension".
Are there ways you can use the importer to get reasonable/acceptable
performance (at least, from the perspective of some users).
Yes. Please see guidance in this forum and in:
http://jazz.net/library/techtip/68
Were you initially given the appropriate guidance (both for whether and
how to use the CC Synchronizer).
I can't be sure, but very possibly not. That's what we're working on
fixing now, both in this forum discussion and in your ongoing
interactions with IBM support.
Also, please keep in mind that these forum posts are not primarily
directed at your particular issue (IBM support is responsible for that),
but rather for providing information to the RTC community as a whole on
this topic. So when I say "best practice", I'm providing a
recommendation to the RTC community, not saying that this is what you
need to do for your particular case (for one thing, I haven't been
provided with enough information on your particular case to provide such
a recommendation).
Cheers,
Geoff
On 6/2/2010 4:23 AM, cdlee wrote:
Are there any performance issues with the CC Synchronizer that are
currently being worked on?
Yes. Please see work item 114744: "Importer doesn't scale very well in
the initial treesize dimension".
Are there ways you can use the importer to get reasonable/acceptable
performance (at least, from the perspective of some users).
Yes. Please see guidance in this forum and in:
http://jazz.net/library/techtip/68
Were you initially given the appropriate guidance (both for whether and
how to use the CC Synchronizer).
I can't be sure, but very possibly not. That's what we're working on
fixing now, both in this forum discussion and in your ongoing
interactions with IBM support.
Also, please keep in mind that these forum posts are not primarily
directed at your particular issue (IBM support is responsible for that),
but rather for providing information to the RTC community as a whole on
this topic. So when I say "best practice", I'm providing a
recommendation to the RTC community, not saying that this is what you
need to do for your particular case (for one thing, I haven't been
provided with enough information on your particular case to provide such
a recommendation).
Cheers,
Geoff
On 6/2/2010 4:23 AM, cdlee wrote:
Hi Geoff,
if you don't think you have any performance issues about your
product,
then IBM should have the responsibility to tell customer that this
product is suitable for the case you metioned only.
why i feel CC Connector applies to our case? good question, because
IBM told us about that.
Regards,
Makson
It sounds like there may be some misunderstanding on when the CC
Synchronizer should be used. If this is just a producer-consumer
relationship, where one company is producing files in ClearCase that are
being used by another company using RTC, then it is sufficient to just
have a ClearCase view and an RTC sandbox on a single host. When you are
ready to send the files from ClearCase to RTC, just copy all the files
from the ClearCase view to the RTC sandbox, refresh your RTC workspace
for that sandbox, and check in the result. This will be very fast and
simple.
The CC Synchronizer is for cases where both teams are making changes in
parallel to the same set of files. In that case, the fast and simple
approach cannot be used. But in that case, waiting until 1000's of
files have been changed before synchronizing will usually result in a
large number of difficult merges, thus motivating the more frequent
synchronization. To allow for more frequent synchronization, the "build
candidate" stream would be synchronized, rather than the "successful
build" stream.
An edge case is where you usually have no conflicts, but there is a
small probability that one will occur. In that case, you don't want to
use the fast/simple copy approach, but the careful checking done by the
CC Synchronizer is too slow for you. In that case, your choices are:
- change your practices to remove the possibility that a conflict that a
conflict has occurred (so you can use the simple/fast approach)
- change your practices so that synchronization is performed more frequently
- have both teams use the same SCM system until the Synchronizer
performance is improved (as indicated in other messages, we work on
performance every release).
Cheers,
Geoff
On 6/2/2010 5:53 AM, joseph wrote:
Synchronizer should be used. If this is just a producer-consumer
relationship, where one company is producing files in ClearCase that are
being used by another company using RTC, then it is sufficient to just
have a ClearCase view and an RTC sandbox on a single host. When you are
ready to send the files from ClearCase to RTC, just copy all the files
from the ClearCase view to the RTC sandbox, refresh your RTC workspace
for that sandbox, and check in the result. This will be very fast and
simple.
The CC Synchronizer is for cases where both teams are making changes in
parallel to the same set of files. In that case, the fast and simple
approach cannot be used. But in that case, waiting until 1000's of
files have been changed before synchronizing will usually result in a
large number of difficult merges, thus motivating the more frequent
synchronization. To allow for more frequent synchronization, the "build
candidate" stream would be synchronized, rather than the "successful
build" stream.
An edge case is where you usually have no conflicts, but there is a
small probability that one will occur. In that case, you don't want to
use the fast/simple copy approach, but the careful checking done by the
CC Synchronizer is too slow for you. In that case, your choices are:
- change your practices to remove the possibility that a conflict that a
conflict has occurred (so you can use the simple/fast approach)
- change your practices so that synchronization is performed more frequently
- have both teams use the same SCM system until the Synchronizer
performance is improved (as indicated in other messages, we work on
performance every release).
Cheers,
Geoff
On 6/2/2010 5:53 AM, joseph wrote:
I would try to make the discussion move forward to solution and check
if CC connector can match the requirement in the next release.
For Lee's requirement, the two teams in the different side of CC
Connector belong to two companies. In stead of frequently sync,
enough testing before sync is the BEST PRACTICE to them. That's why
changes will be accumulated in stead of immediately sync. I think
even in the same company, each team should well test their code
before deliver it to integration.
Currently sync 1000 file from RTC to CC takes about 1 hours in the
current version. If Lee can get the average number of files for
incremental sync and the acceptable time in real case (eg 3000 files
in 1 hours), we can have breakthrough. It's more meaningful than
discuss what's the best practice I think.
Hi Geoff,
The 3rd case you mention "usually have no conflicts, but there is a small probability that on will occur" is the most closed one to our scenario.
From IBM Sales view, of course I prefer use the out-of-box feature instead of customized one. (Even it is not very difficult) I have more creative usages of CC connector. But anyway, unless the performance improved to certain level. I can't propose any other solution to any customer.
The 3rd case you mention "usually have no conflicts, but there is a small probability that on will occur" is the most closed one to our scenario.
From IBM Sales view, of course I prefer use the out-of-box feature instead of customized one. (Even it is not very difficult) I have more creative usages of CC connector. But anyway, unless the performance improved to certain level. I can't propose any other solution to any customer.
An edge case is where you usually have no conflicts, but there is a
small probability that one will occur. In that case, you don't want to
use the fast/simple copy approach, but the careful checking done by the
CC Synchronizer is too slow for you. In that case, your choices are:
- change your practices to remove the possibility that a conflict that a
conflict has occurred (so you can use the simple/fast approach)
- change your practices so that synchronization is performed more frequently
- have both teams use the same SCM system until the Synchronizer
performance is improved (as indicated in other messages, we work on
performance every release).
Cheers,
Geoff
Hi Geoff,
really thanks for your detailed explanation, we don't expect you to deal with particular issue here too, but i think it is good to let others know about these (limitations or what you said about "best practices"), at least, they can judge if the CC Connector fit their requirements now.
Regards,
Makson
really thanks for your detailed explanation, we don't expect you to deal with particular issue here too, but i think it is good to let others know about these (limitations or what you said about "best practices"), at least, they can judge if the CC Connector fit their requirements now.
Regards,
Makson
Hi Makson,
Yes, the purpose of carrying on these discussions in public is exactly
that, to give the user community a heads up on current limitations and
best practices of the tools.
And I totally understand your frustration when a tool doesn't do what
you want it to do (especially when you were told that it could do that!).
And in case anyone is wondering why synchronizing a file is so much
slower than just checking out a file from one repository and checking it
into the other one, some of the challenges of the CC Synchronizer include:
- RTC and ClearCase have different directory versioning models (an RTC
file/directory knows its parent, while a CC directory knows its
children). So just pushing versions across is not semantically feasible.
- the CC Synchronizer has to work with all supported releases of
ClearCase on all platforms, which pretty much means that cleartool needs
to be used to talk to ClearCase, and cleartool was never designed to
implement a synchronizer.
- all forms of rename and delete/restore must be accurately replayed, so
that two synchronized streams can be correctly merged from either
repository.
- conflicts can occur and need to be reliably tracked and set up for
easy/intuitive merging
- both RTC and ClearCase have customizable process definition mechanisms
that must be respected, so we can't use a "back door" into the
repository to improve efficiency, since this could violate the user's
process.
- etc. (:-)
Cheers,
Geoff
On 6/2/2010 10:37 PM, cdlee wrote:
Yes, the purpose of carrying on these discussions in public is exactly
that, to give the user community a heads up on current limitations and
best practices of the tools.
And I totally understand your frustration when a tool doesn't do what
you want it to do (especially when you were told that it could do that!).
And in case anyone is wondering why synchronizing a file is so much
slower than just checking out a file from one repository and checking it
into the other one, some of the challenges of the CC Synchronizer include:
- RTC and ClearCase have different directory versioning models (an RTC
file/directory knows its parent, while a CC directory knows its
children). So just pushing versions across is not semantically feasible.
- the CC Synchronizer has to work with all supported releases of
ClearCase on all platforms, which pretty much means that cleartool needs
to be used to talk to ClearCase, and cleartool was never designed to
implement a synchronizer.
- all forms of rename and delete/restore must be accurately replayed, so
that two synchronized streams can be correctly merged from either
repository.
- conflicts can occur and need to be reliably tracked and set up for
easy/intuitive merging
- both RTC and ClearCase have customizable process definition mechanisms
that must be respected, so we can't use a "back door" into the
repository to improve efficiency, since this could violate the user's
process.
- etc. (:-)
Cheers,
Geoff
On 6/2/2010 10:37 PM, cdlee wrote:
Hi Geoff,
really thanks for your detailed explanation, we don't expect you to
deal with particular issue here too, but i think it is good to let
others know about these (limitations or what you said about
"best practices"), at least, they can judge if the CC
Connector fit their requirements now.
Regards,
Makson
page 2of 1 pagesof 2 pages