Hi,we’re currently reviewing Continua CI and playing around with both version 1.0 and 1.5 beta. First of all, great feature list: I’m excited on all the new possibilities.We’re encountering one serious performance issue with the Repository Cache. At our company we’re mainly using Subversion and one of the repositories currently synced is SVN. I have added one of our large SVN repositories to Continua. Once the final checkout/cache sync was completed (took a while, no problem, I understand this can take time) it al looked ready to go.However, a new Subversion commit triggers the Continua Repository Cache Updater, that will now take approx. 21 minutes for each Subversion commit. I tried to analyze what the server and/or agents are doing, but my quick analysis is:* Updating the change from Subversion to Continua’s repository folder takes less than 1 minute. (I guess a few seconds)* Updating the Continua Server’s cache (which seems to be Mercurial/HG) takes 21 minutes. During this period, the hg process fully occupies 1 system core (e.g. 50% load on dual-core processor)* When a build is started, the sync between Continua Server and Agent takes less than 1 minute. During this process, I guess the new Mercurial/HG revision is pushed to the Agent. This is fast again.Additional information on the Continua Server’s Repository Cache folder:* Size of exported Subversion folders/files: 32.379 files, 2.32GB* Size of Subversion .svn admin area: 38.194 files, 2.20GB* Size of Mercurial .hg admin area: 52.772 files, 1.01GBCould this be a specific server setting, configuration issue or is our Subversion Repository “way beyond spec”?I understand you should try to keep repositories small, keep out large files, etc. This repository contains multiple products which we are not eager to migrate to different repositories, considering we’d like to keep the history. I haven’t found any mechanism to limit the sync: We currently monitor a single branch, /trunk/.Advise regarding this issue is welcome! Looking forward to any helpful response
Hi Remko,
Can you post your repository settings (or send them to support@finalbuilder.com)? We are especially interested in the branch and external settings. Also can you provide some details of the folder structure of your repository.
When Continua detects a changeset it switches the repository cache working folder to the branch for that changeset, updates the working folder and then commits the working folder to a Mercurial branch. If your repository setting matches several branches which are significantly different then I suspect the delay is in switching between those branches and updating the working folder.
Generally, if we think of branches of variants of the same source code then the switching and updating is quick. If you are using branches which are split between different projects/components then we are constantly exporting a lot of new files to the working folder and this can take time.
The recommendation is to use separate Continua repositories for repository folders associated different projects or components. e.g. If the repository structure is
/project a/trunk
/project a/branches/v1
/project a/branches/v2
/project b/trunk
/project b/branches/v1
/project b/branches/v2
/project b/component x/trunk
/project b/component x/branches/v1
/project b/component x/branches/v2then set up three repositories in Continua. One with default path “/project a/trunk” and branches path “/project a/branches”, another with default path “/project b/trunk” and branches path “/project b/branches” and another with default path “/project b/component x/trunk” and branches path “/project b/component x/branches”.
You can get more information about the process and the specific commands which are taking the most time by enabling debug logging
Dave, Thanks for your reply. I’ll try to send you an email today with all details. Last Friday I also encountered into some other repository sync issues, including timeouts, so we may have a specific configuration issue here.