Slow Performance over VPN

[CT-Mike]

I have a remote office with 4 developers connecting to the main office on a DSL connection (3M/768K) through a VPN. We are using Vault 3.1.2.3511.

These developers are all using one repository with a DB size of 181 MB, 246 folders, & 8659 files. They are all complaining of slow performance.

We are using no folder security, we run maintenance plans on the Vault Server DB once per week for reorganization and to update statistics, and we run Defrag software on the server each night.

All users are using Active Directory Authentication, but other than that the Vault Admin settings are defaults from the install.

We have another 4 developers in the main office using the same repository and everything is working fine for them on the local LAN.

The remote developers are reporting various problems:
1. Login time is reasonable but then it takes 5 minutes to bring up the folder list in the repository.
2. Check-out time is OK, but it takes 5-10 minutes to check-in 1-3 files and it takes longer to un-do a check-out.

These problems seem to occur in both the Vault Client and the VS2003 IDE.

Any ideas how I can narrow down the problem?

Thanks,
Mike

[dan]

Vault doesn't normally behave this way over VPN, especially on such a small repository and so few users. Are there settings on the VPN that might affect data transfer speeds?

[CT-Mike]

No - I know the VPN is correct because we just went through a problem involving Enterprise Manager and packet fragmentation when connecting to one of our customers over another VPN configured on the same VPN/Firewall box. We had to get Microsoft involved, and to make a long story short, we made config changes on the box that optimized the VPN and solved the problem.

I actually thought that was going to solve the Vault problem as well but it had no effect.

[paolohu]

don't know if this will help or not but it's worth a shot. i had another web service based application that had horrible performance over VPN and worked fine otherwise, i turned off keep alives on the iis site it was running on and it started performing much better.

[dan]

This jogs my memory for another possible cause: Sometimes reverse DNS lookups cause slow downs as well. You can turn this off for the Vault server in the Admin tool under Server Options and see if that affects anything...

[CT-Mike]

I am at the satellite office today digging into the problem and here is what I found.

The problem with Vault appears to occur because we are using semi-isolated development and the VS working folders reside on a share on the remote Web Server instead of the local machine.

Per the KB Article 927: “By default, Vault stores a copy of files in your working folders in the %appdata% folder (usually located in a folder like C:\Documents and Settings\username\Application Data\SourceGear )”. It appears that during a store or retrieve the files are being copied, across the DSL, to the local machine for caching and then back down to the remote server, across the DSL, at the same time.

Per the same article: “Vault has an option to store these files underneath your working folder in an _sgvault folder instead of in your appdata folder. In the Vault GUI client, go to Tools->Options->General and select the option for "Store working folder data inside working folders" to store them under the working folder”.

The ‘Store Client Cache Folder’ option in the Vault Client only allows the Local Settings Folder or a different folder.

Could we set this to a folder on the remote (Main Office) Web Server to eliminate the problem or will everything still make a round trip on the DSL?

We also verified that doing a Get or Check-out to a folder on the local machine from the Vault Client works fine.

[jclausius]

Hope I'm not interrupting...

Could we set this to a folder on the remote (Main Office) Web Server to eliminate the problem or will everything still make a round trip on the DSL?

Take a look at the Local Files -> Cache/Backup Locations. You may want to see if changing the settings to store things in a different folder or within the Working Folders themselves help things in your situation.

[CT-Mike]

Jeff -

That's my question.

In the Vault Client, Options, Local Files, Cache/Backup Locations, there are 3 options:
Store Client Cache Folder
Store Working Folder State/Baseline Files
Store Backup Files

Store Working Folder State/Baseline Files is grouped inside Store Client Cache Folder.

So, if the working folders are not on the local machine, will the files have to traverse from the Vault Server through the local machine running the Client to get to the working folders?

For Store Working Folder State/Baseline Files, if I select 'In Working Folders' does this override the 'Store Client Cache Folder' setting, i.e. are there 2 things stored by Vault (Working Folder State/Baseline Files + Backup Files) or 3 things (Working Folder State/Baseline Files + Backup Files + something else in the Client Cache Folder)?

[jclausius]

So, if the working folders are not on the local machine, will the files have to traverse from the Vault Server through the local machine running the Client to get to the working folders?

If you are using working / cache folders on a remote machine, I can see why you are having problems. The Vault client does a lot of checking of the files for timestamps, file lengths, CRC checks, reading of directory structures, etc.

Additionally, if someone lost their network connection, they would also lose access to their source files.

So, setting working folders to local disk subsystems would be the optimal configuration for Vault.

For Store Working Folder State/Baseline Files, if I select 'In Working Folders' does this override the 'Store Client Cache Folder' setting, i.e. are there 2 things stored by Vault (Working Folder State/Baseline Files + Backup Files) or 3 things (Working Folder State/Baseline Files + Backup Files + something else in the Client Cache Folder)?

The Client Cache Folder contains more information than just baseline file info. This folder contains some information about your repository settings, checkout lists, tree structure etc. This directory controls where that information is stored.

The Working Folder / Baseline option lets the Vault client know where you want to store files that the client uses to determine changes within Gets / Commits. You can use this option to store them within the directory above, or store them within the working folder itself. You can find these on disk in the _sgvault folders.

HTH