Vault performance / Retrieving repository structure...
Moderator: SourceGear
We've tweaked the TreeManagerSize several times, but we still run into slowness. Part of the problem is that when the Vault server is restarted, it NEVER caches "older" trees in memory, it only caches new trees moving forward. So each time you get a DB diff for a tree that isn't in memory, instead of being a one-time occurance, it occurs every time another client requests the same tree diff.
Yes. That is indeed one of the problems.
We are actively working on these areas. Along with improved checkout handling, users can expect better timings in the tree delta routines (as well as sending the whole tree for those on faster connections) in the upcoming maintenance release to Vault 3.5.
We are actively working on these areas. Along with improved checkout handling, users can expect better timings in the tree delta routines (as well as sending the whole tree for those on faster connections) in the upcoming maintenance release to Vault 3.5.
Jeff Clausius
SourceGear
SourceGear
Did you already finish the maintenance release?
Hi!
As we are suffering from nearly identical problems like crt told (e.g. Getting a project via SGV client with slow response, opening VS2005 and having the same slow response again - even if the diff was already transmitted), I am very interested when this maintenance release will be finished and when we will be able to use it.
Like crt told I would prefer having a switch to completely shut down the caching of the trees and transmit the current one every time. That would be a lot faster for us.
When can we expect the release?
As we are suffering from nearly identical problems like crt told (e.g. Getting a project via SGV client with slow response, opening VS2005 and having the same slow response again - even if the diff was already transmitted), I am very interested when this maintenance release will be finished and when we will be able to use it.
Like crt told I would prefer having a switch to completely shut down the caching of the trees and transmit the current one every time. That would be a lot faster for us.
When can we expect the release?
It will be in Vault 3.5.2, scheduled sometime in Q1 2007.
Vault 3.5.2 has two changes in regards to this issue:
a) The delta routine has been re-designed taking the database repository delta down to mere seconds in most cases. Proper database maintenance will be key, so the queries remain fast. This will be useful for 100Mbps or lower network connections or when an entire repository tree is very large.
b) The option to transfer the full tree instead of using the database delta on a cache miss.
Vault 3.5.2 has two changes in regards to this issue:
a) The delta routine has been re-designed taking the database repository delta down to mere seconds in most cases. Proper database maintenance will be key, so the queries remain fast. This will be useful for 100Mbps or lower network connections or when an entire repository tree is very large.
b) The option to transfer the full tree instead of using the database delta on a cache miss.
Jeff Clausius
SourceGear
SourceGear
Re: Did you already finish the maintenance release?
Note, there is something wrong with your configuration in a case like this. Once a delta has been received by the client, any future clients (IDE, command line, or GUI based) will not require the delta.NTTAKR wrote:(e.g. Getting a project via SGV client with slow response, opening VS2005 and having the same slow response again - even if the diff was already transmitted)
You may want to start a new thread about this including Vault's version. There were some known issues of earlier versions of Vault when using the .Net 2.0 Framework - one of which is constantly transferring the repository tree.
Jeff Clausius
SourceGear
SourceGear