"Get Latest Version" performance problem after 3.0

tbreyman · Post by **tbreyman** » Thu Jun 30, 2005 9:43 am

We just upgraded from Vault 2.0.6 to 3.0.7 yesterday. Most of the client computers are running smoothly. However one of the computers is having significant performance problems after the installation. Before the upgrade, the computer had no performance problems getting the latest version of the main branch to an empty folder. After the upgrade, the computer has significant performance problems performing the same operation (each file takes 1-2 seconds to pull down from the local server).

Some pertinent parameters:

- Windows 2000 with all the latest updates applied
- 512 GM RAM
- Working folder is on a local disk drive with 12 GB free
- 11386 files in 1077 folders in the repository
- Vault server is in the same location as the client

A 30 MB file located on the same server as the Vault server copies to the client machine in a few seconds so the network throughput does not appear to be an issue.

Any ideas?

Todd Breyman
SunGard Insurance Systems, Inc.

lbauer · Post by **lbauer** » Thu Jun 30, 2005 10:20 am

Is the client computer using the Vault GUI Client or IDE client to do the Get?

Are other operations slow, or just Get latest?

Are there any errors or other info in the Vault server log that correspond to the time period of the Gets by this client machine?(%windir%\Temp\sgvault\sgvault.log)

If the Vault client is establishing file baselines, a first get would take longer than subsequent gets of the same file. Have these files been retrieved previously by the client?

Is client-side logging enabled for that client? Vault 3.0.7 does a lot more logging and that could slow things down.

tbreyman · Post by **tbreyman** » Thu Jun 30, 2005 10:56 am

Is the client computer using the Vault GUI Client or IDE client to do the Get?

Vault GUI Client

Have these files been retrieved previously by the client?

No. This computer performs weekly builds and ALWAYS starts with an empty working folder. However this has always been the case and was never a problem with 2.0.6.

Are other operations slow, or just Get latest?

Since the repository hasn't been brought down yet, only "GET LATEST".

Are there any errors or other info in the Vault server log that correspond to the time period of the Gets by this client machine?

See attached log. The client logged in, performed a GET LATEST VERSION, and then an ABORT after performance problem was detected.

Is client-side logging enabled for that client?

Client side logging is DISABLED.

Todd

lbauer · Post by **lbauer** » Thu Jun 30, 2005 12:06 pm

Doesn't seem to be a server-side problem:
----6/30/2005 12:43:24 PM Librarian--SIS-ATL-CFARIN1(168.162.72.65)--SSL Disabled Beginning file download
<snip>
----6/30/2005 12:44:31 PM Librarian--SIS-ATL-CFARIN1(168.162.72.65)--SSL Disabled Ending download process

Just about a minute for the download.

It's not clear why things would be slower for this particular client.

You could try deleting the client-side cache files and hidden state folders (_sgvault) --perhaps there's some problem with them that will go away when they're recreated by the client.
http://support.sourcegear.com/viewtopic.php?t=6

The first download after deleting the _sgvault directory will cause new baseline files to be retrieved. After that, gets should be faster because only file deltas will be retrieved.

tbreyman · Post by **tbreyman** » Thu Jun 30, 2005 12:33 pm

----6/30/2005 12:43:24 PM Librarian--SIS-ATL-CFARIN1(168.162.72.65)--SSL Disabled Beginning file download
<snip>
----6/30/2005 12:44:31 PM Librarian--SIS-ATL-CFARIN1(168.162.72.65)--SSL Disabled Ending download process

Just about a minute for the download.

It's only about a minute for the download because I aborted the job. According to the status line, the download would have taken hours.

You could try deleting the client-side cache files and hidden state folders (_sgvault)

Already tried that.

The first download after deleting the _sgvault directory will cause new baseline files to be retrieved. After that, gets should be faster because only file deltas will be retrieved.

This will not work because of our business practices on the libary computer - we always begin with an empty working folder. In addition, we are storing the _sgvault files in the working folder on that computer.

----

This is a real problem for us. Are there any diagnostics we can use to find out what is going on? ...to find out what changed from 2.0.6?

Todd

lbauer · Post by **lbauer** » Thu Jun 30, 2005 4:18 pm

Deleting the hidden state folder (_sgvault) means the client has to refetch a new baseline each time, and results in poorer performance than if the Vault client only retrieves changes to the file (deltas).

Are your other users doing the same thing? If they still have their _sgvault folders, that could be why they are experiencing better performance. The _sgvault folder does not need to be in the working directory: if you uncheck the option to store it in the working directory the files will be stored in the user's %appdata% directory. (Tools->Options->General.)

Does the Get time improve if you don't delete the _sgvault folder?

What else is different on that client machine? Do you have real-time anti-virus software checking every read/write? Could the disk be getting fragmented?

You could also enable client-side logging to see if there are any clues to the slowdown:
http://support.sourcegear.com/viewtopic.php?t=1534

I'd suggest logging all classes.

tbreyman · Post by **tbreyman** » Fri Jul 01, 2005 6:16 am

We appear to have narrowed the specifics of the issue. When the user specifies a normal folder as the working folder, there is no performance problem. However, when the user specifies a mapped drive (that points to that same folder) as the working folder, performance plummets.

lbauer · Post by **lbauer** » Fri Jul 01, 2005 7:33 am

Yes, a mapped drive introduces network-related variables that can affect performance. Although the Vault Client can use a mapped drive, it's better to use a direct path on the local machine.