Skip to main content
T
tcbdon
Inspiring
April 28, 2006
Answered

Unraveling slow RoboSource performance issues

  • April 28, 2006
  • 2 replies
  • 799 views
Greetings all,

I am a Robo-noob (noobie, novice, etc) though not new to computers and databases and such. We have a team of 5 writers all working on separate projects but under the same RoboSource version control. We are experiencing some serious performance issues: projects can take over an hour to check out or in; not all users can see projects; "rename" doesn't get rid of the old rather makes a copy under the new name(?); etc.

I am trying to baseline "normal" behavior for RoboSource Control as well as some best practices for multiple users. I am wondering if there is something more in depth to describe the RoboSource control engine, and possibly maintenance tasks to help what appears to be a jumble of nodes that are not all necessary, too many 'admin' users, etc. I expect that "cleanup" will solve a lot of our problems.

So, rather than go into each problem in the forum, I would prefer to find good resource and tackle this thing iteratively.

Thanks for any useful suggestions

Don
This topic has been closed for replies.
Correct answer tcbdon
I wanted to update the forum regarding this performance issue. Upon further investigation, the PC acting as server was noted to have been running for 6 months without interruption. Also, that it had 512MB of RAM but the ROBOSOURCECONTROL service was consuming 350MB of it. The rest of the system resources were probably swapping busily. A reboot has cleared that up and RSC performance is splendid - from 30-60 minutes, down to about 15 seconds for a GET or a check-in.
We suspect there is a memory leak in RSC but I may start a separate thread to get some guidance on how to define and report a bug for this package.

Thanks all

don

2 replies

T
tcbdonAuthorCorrect answer
Inspiring
May 3, 2006
I wanted to update the forum regarding this performance issue. Upon further investigation, the PC acting as server was noted to have been running for 6 months without interruption. Also, that it had 512MB of RAM but the ROBOSOURCECONTROL service was consuming 350MB of it. The rest of the system resources were probably swapping busily. A reboot has cleared that up and RSC performance is splendid - from 30-60 minutes, down to about 15 seconds for a GET or a check-in.
We suspect there is a memory leak in RSC but I may start a separate thread to get some guidance on how to define and report a bug for this package.

Thanks all

don
Captiv8r
Captiv8r
Legend
April 28, 2006
Hi Don

From what you posted, it would seem to indicate each of the 5 help authors are "captiain of their own ship" so to speak, and are only responsible for their individual projects. So why the use of RoboSource control? Why even introduce this layer of complexity in the mix? What does it offer you need?

I really wish I had some nifty advice here about what to do. But I tend to only show folks how to access RSC in the classes I teach. To be very honest, if it were me, I'd probably opt for using something like Microsoft Visual Source Safe. And I actually have used VSS with RoboHelp in the past. Long before RoboHelp offered any "integration" or its own RSC.

I'm not saying RSC is a "bad" product here. Only that there seem to be far more issues reported with it than there are answers. And performance is certainly among the cited issues. I'm sure you may well have your reasons for using it (or any other product for that matter) but based on what little we know at this point, it would seem overkill.

Sincerely... Rick
T
tcbdonAuthor
Inspiring
April 28, 2006
Thanks Rick,

We have actually had that discussion here as well. This is a startup but growing quickly project. In a short while writers will indeed be collaborating on the same projects, working on shared files, etc. That will benefit from source control. The other advantage is a bit weaker; it is a way to get everything onto a shared drive in a cohesive manner so it can be backed up more regularly than local files might be.
All that to justify using version control, whether RSC or VSS.
However, since this is a startup project with lots of structural changes to document names, numbering schemes, hierarchy, etc changing rapidly, it seems that source control may be a bit premature. We might prefer to wait for things to get more stable before imposing that layer. Come up with a different tactic for backups.
In the mean time, I will read and experiment with it to get a better sense of how to structure things more robustly.

Thanks for your insight.

don
Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices