Very slow "get latest"

nolic · Post by **nolic** » Wed Apr 26, 2006 2:21 am

I just installed SourceGear to evaluate it and imported a 2Gb VSS database into it. The import went well and relatively fast, running every thing on the same computer (a VMWare workstation). Then I performed a "get latest" on the whole tree to a new directory, that went fast too.

My problems start when I run the client on an other computer. I tested the client both on an other virtual machine using an internal network and on the actual computer using a bridged network. A "get latest" or a "show difference" of the whole tree runs very slow but there is no CPU or network load on both the client and server.

I am using MSSQL 2000 SP4 and IIS 5 on XP pro. Any idea?

-----------------------------------

Client Information
Vault Client Version: 3.1.8.3771
.Net Framework Version: 1.1.4322.573
Operating System: Microsoft Windows XP Professional
Service Pack: 2.0
OS Version: 5.1.2600
Total Physical Memory: 511.48 MB
Time Zone: (GMT+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna

Server Information
Vault Server Version: 3.1.8.3771
.Net Framework Version: 1.1.4322.2032
Operating System: Microsoft Windows XP Professional
Service Pack: 2.0
OS Version: 5.1.2600
Timezone: (GMT+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
SQL Version: Microsoft SQL Server 2000 - 8.00.2039 (Intel X86)
May 3 2005 23:18:38
Copyright (c) 1988-2003 Microsoft Corporation
Personal Edition on Windows NT 5.1 (Build 2600: Service Pack 2)

License Information
0 serial number(s):

lbauer · Post by **lbauer** » Wed Apr 26, 2006 1:28 pm

If Vault works fine from the server machine itself, then there may be something on the other client machines or in the network connection that is causing a slowdown.

Could there be a firewall or anti-virus program on the other client machines that are interfering with the download?

You can also test general network speeds between the Vault Server and a client machine with this test:

Connect to http://yourvaultserver/vaultservice from the client machine that is experiencing a slowdown. You'll see the Vault Home Page. Use either "Install the Admin Tool" or "Install the Client." This will download the .msi file for the installer. Does this seem to take a long time, given the size of the file? Since this download does not involve the Vault Server itself, it may help determine if there is a general problem with retrieving files over the network.

nolic · Post by **nolic** » Thu Apr 27, 2006 12:39 am

I did this test from the actual workstation which has an anti-virus and it took about 2 seconds to transfer the client. On the virtual workstation it took 1 second, like when I tried it on the server itself.

When a get-latest starts, it seams to be fast the first half minute. Then it seams to stale (showing the name of a small file <1kb). After a while it continues and stale again. On the server you can see peaks of activity every ~3min. I tried to disable logging and DNS look-up in IIS.

In your opinion, how does the speed of a get latest in SourceVault compares to VSS ?

lbauer · Post by **lbauer** » Thu Apr 27, 2006 7:40 am

We can troubleshoot this further by looking at the Vault Server and Client logs to see if the slowdowns appear in the logs.

Enable debug logging in the Vault Admin Tool->Server Options logging.

Also enable logging for the Vault GUI Client. Log all classes, per this KB article:

http://support.sourcegear.com/viewtopic.php?t=1534

Then do a Get, preferably one that captures a couple of slowdowns but not so large as to make reading the logs unmanageable. Email the logs to Linda at SourceGear.com.

In your opinion, how does the speed of a get latest in SourceVault compares to VSS ?

We have not done comparison testing, since there are so many variables -- you're not comparing apples to apples. Vault may be faster for some operations; slower for others. It depends too, on whether you're working remotely or on the LAN.

arden_dan · Post by **arden_dan** » Mon May 15, 2006 5:02 am

I'd be interested to see what the outcome is here, because I also have experienced a similar problem.

Our main repository has 630,000 files and 20,000 folders. If I do a get on one tree within the repository (about 20000 files), it can take in excess of 30 minutes.. most of this time is with the stop/start behaviour as described above.

Once in a blue moon, the stop/start will not happen and the get will take 4 or 5 minutes.

I was exploring the idea that storing state in working folders was slower than using the cache folder, but I have nothing conclusive yet.

Please post the outcome of this logging operation here.

Thanks,
Dan

dan · Post by **dan** » Mon May 15, 2006 8:10 am

Dan, you might also want to enable client logging and see where the slowdown seems to be.

Are either of you using the 2.0 framework on the client side, and is the client in a different timezone from the server? An issue recently cropped up with that configuration that caused slowdowns.