Vault Server 3.07. Our sgvault DB is currently 4 GB.
I have noticed that Vault operations are slower. I am doing a test when the server has the lowest activities and our server has plenty of hardware resources.
Question1: Is the sgvault DB size an important factor to the overall performance? If yes, what is the estimated threshold? Just an approx value to give an idea is enough.
Question2: if DB size is not the main factor to slow down Vault operations, what could that be? Repository size? Nb of concurrent access? Nb of files? etc?
Thanks in advance.
Relation between sgvault DB size and performance
Moderator: SourceGear
Slowness is perceived on log in, check in/out and opening VS2003 solution. I said "slow" because last month, things seemed to be faster. Our server has plenty of hardware resources. The network speed is not too bad. There was 10 more users since last month.
Folder security is enabled. This is a requirement.
Can you please help on how to diagnose the slowness?
Folder security is enabled. This is a requirement.
Can you please help on how to diagnose the slowness?
- Do your "GET" speeds seem slow as well?
- Have you done any VSS imports or large branches right around the time you noticed a problem?
- Have you done any database maintenance with statistics, index defrags, index rebuilds, etc since last month?
- Although I said DB size is not that important to Vault, it is important to SQL Server. Is it possible the database grew into a new section of disk that is fragmented? Shutting down the database and defragging would help there.
As for diagnosing, I can assist on the server. You need to place the server in Debug Log mode. See the Admin Tool's help for this setting. When the server is placed in Debug Log mode, all operations are logged with their times. From this file, we should be able to spot any type of bottlenecks for Vault operations.
- Have you done any VSS imports or large branches right around the time you noticed a problem?
- Have you done any database maintenance with statistics, index defrags, index rebuilds, etc since last month?
- Although I said DB size is not that important to Vault, it is important to SQL Server. Is it possible the database grew into a new section of disk that is fragmented? Shutting down the database and defragging would help there.
As for diagnosing, I can assist on the server. You need to place the server in Debug Log mode. See the Admin Tool's help for this setting. When the server is placed in Debug Log mode, all operations are logged with their times. From this file, we should be able to spot any type of bottlenecks for Vault operations.
Jeff Clausius
SourceGear
SourceGear
A quick survey, my team members say that get is may be a little bit slower than before but the GET speed is still acceptable. The slowest operations are check in/out. Next is opening VS solutions and log in Vault client.
DB Maintenance is done weekly. I'll check that again.
Just curious, is there any technical reason for a check in/out to be much slower than Get Latest?
DB Maintenance is done weekly. I'll check that again.
Just curious, is there any technical reason for a check in/out to be much slower than Get Latest?
When a user checks in/out of the repository, the client refreshes its client side cache.
With security enabled, there are some security related checks which go on during the refresh as well as the check in/out so no invalid information is sent to the client.
One thing we're working on in Vault 3.1 is improvement in performance in some areas when folder security is enabled. If you temporarily disable folder security, and give things a try, does that make a significant improvement?
With security enabled, there are some security related checks which go on during the refresh as well as the check in/out so no invalid information is sent to the client.
One thing we're working on in Vault 3.1 is improvement in performance in some areas when folder security is enabled. If you temporarily disable folder security, and give things a try, does that make a significant improvement?
Jeff Clausius
SourceGear
SourceGear