"Getting project sources" runs slowly

When our project is at the "Getting project sources" stage of the build process, it seems TeamCity is taking an excessive amount of time to pull the source. Looking at the agent, it is barely using any CPU, memory, or hdd access during the stage, so it hardly seems like it is actually checking out the source. Even in a stripped down build configuration, it can take up to 40 minutes to pull the source before it will even move on to looking for changed files. In comparison, I can pull the full source directory on my system using Visual Studio 2005 in about 5 minutes or so, and our previous CC.NET system performed about the same in 5-7 minutes.

We are using Team Foundation Server 2005 for source control, and the build agents are set to read from an MSBuild file for instructions. The problem with "getting project sources" occurs before it even gets to the MSBuild file, so I'm not worried with what it is doing.

Our current testing configuration for TeamCity consists of TC 4.0 EAP server on a dedicated dual-core system with 4gb ram, and a corresponding 4.0 EAP agent on a dedicated dual-core system with 2gb ram. Both run Windows XP Professional with a minimum of unrelated system services.

I've seen this issue on different systems in TeamCity 2.1, 3.0, 3.1, 3.1.1, and now 4.0, so I wanted to reach out and see if anyone had suggestions. Is anyone else seeing frustratingly slow source pulls? If you did, what did you do to fix it?

5 comments

When we used VSS for version control, we saw similar problems. I believe that TeamCity must first check out the files on the server and then send them (via HTTP) to the client. The problem with this was that for our project we had many small files, which when transfered this way, takes quite a while. My guess is that is a large part of the problem.

BTW... I've always wondered why TeamCity didn't zip up the sources, and artifacts for that matter (or maybe provide a checkbox to control the behavior) when sending resources between the Server and Agents.

0

We are also seeing this behavior with CVS (on a Linux box) and TeamCity 3.1.1 (web server and agent both on Win2k3 machine). It seems to take a really long time to check for changes and get the source. Once it actually starts doing the build things move pretty quickly. It takes TeamCity around 15 minutes to complete our build. Checking out and building by hand don't take anywhere near that long (probably 4-5 minutes max).

Edit, we also get a bunch of messages like this in our teamcity-vcs.log. Not sure if this is what is causing the issue or not:

WARN - jetbrains.buildServer.VCS - Cannot add file to change: /path/to/some/File.java: file date 2008/05/19 12:03:23 -0400 is before requested date 2008/05/16 13:30:30 -0400

Also, this happens when TeamCity is building from HEAD or a branch.

Edited by: Nate Drake on May 19, 2008 11:45 PM

0

Thanks. I have created an issue for you. Please watch/vote for it at http://www.jetbrains.net/tracker/issue/TW-5198

0

TeamCity checks out all changed files to the server, that patch file is build. So the only one file to send is that patch file.
That is true, patch file is not zipped. Please feel free to create an issue in our tracker for that at
http://www.jetbrains.net/tracker/

Thanks!

0

Do you mean VSS for that slow checkout?
Current version of TeamCity scans VSS history to build the patch using VSS COM API.

0

Please sign in to leave a comment.