Long completion of transaction

[vrapp]

Here's the log:

[8/23/2004 09:40:34] Preparing data to begin transaction
[8/23/2004 09:40:34] Beginning transaction
[8/23/2004 09:40:35] Check in $/PIMS/PIMS.adp
[8/23/2004 09:40:49] Ending the transaction
[8/23/2004 09:42:33] Transaction completed successfully

Vault 2.0.4 was hanging in "completing the transaction" for almost 2 minutes. Is that normal?

[lbauer]

It depends. The transaction completed; that's a plus. It took longer than expected. There could be a number of reasons for this.

Are you using the GUI client or IDE client for your checkin?

Do all checkins take this amount of time? Do other Vault operations seem slow?

[vrapp]

It depends. The transaction completed; that's a plus. It took longer than expected.

I'm using Vault Client, checking in an Access project about 10MB large. The file gets transfered to the database in seconds, but then that ending the transaction takes minutes.

Do all checkins take this amount of time?

No. But this file always does. Could it be cause it's large?

Do other Vault operations seem slow?

No.

[lbauer]

Could it be cause it's large?

This might be a factor. When you check in your changes, Vault has to pull the file out of the database, apply the delta, verify the integrity of the updated file, then check it into the database. The larger the file, the longer this operation can take.

However, other things can affect Vault performance, including fragmentation of the drive where the Vault temp folder is located, anti-virus software, etc.

You might try changing your DBBufferSizeKB in Vault.config (Inetpub\wwwroot\Vault Service) from the 256 default to 512 or possibly 1024. This may or may not help, but it's worth a try.

For optimal Vault performance, the machine hosting Vault Server should have plenty of available RAM and fast drives to improve access time to MS SQL Server.

[mlippert]

I just did an add of our entire project tree, which consists of 20,141 files in 922 folders containing 922,886,345 bytes (880 MB), into a brand new Vault 2.0.6 repository residing on a SQL Server (ie not MSDE) using the GUI client not the IDE.

I'm just wondering if the following times are expected:

[10/13/2004 4:49:26 PM] Preparing data to begin transaction
[10/13/2004 4:51:52 PM] Beginning transaction
[10/13/2004 4:52:01 PM] Create folder $/efi
....snip.....
[10/13/2004 5:18:36 PM] Add $/trunk/usr/nlk/translator/utils.hs
[10/13/2004 5:18:40 PM] Ending the transaction
[10/13/2004 6:51:13 PM] Transaction completed successfully

ie the whole process took over 2 hours, and the time from ending the transaction until it completed successfully was 1 hour 33 minutes.

[ericsink]

I just did an add of our entire project tree, which consists of 20,141 files in 922 folders containing 922,886,345 bytes (880 MB), into a brand new Vault 2.0.6 repository residing on a SQL Server (ie not MSDE) using the GUI client not the IDE.

I'm just wondering if the following times are expected:

[10/13/2004 4:49:26 PM] Preparing data to begin transaction
[10/13/2004 4:51:52 PM] Beginning transaction
[10/13/2004 4:52:01 PM] Create folder $/efi
....snip.....
[10/13/2004 5:18:36 PM] Add $/trunk/usr/nlk/translator/utils.hs
[10/13/2004 5:18:40 PM] Ending the transaction
[10/13/2004 6:51:13 PM] Transaction completed successfully

ie the whole process took over 2 hours, and the time from ending the transaction until it completed successfully was 1 hour 33 minutes.

For a transaction that large, those times don't surprise me.

I wish it were faster. We have generally focused on improving the performance of frequent, day-to-day operations. The initial add of a bunch of stuff is still slower than we would like. Luckily, it happens somewhat less often than most operations.

[mlippert]

OK, as far as I'm concerned it's fine that an infrequent operation like this takes a while, I agree with the decision to focus on improving the performance of day-to-day operations first.

It would be nice to be informed while waiting that that this amount of time is expected however.

Anyway, my confusion comes because after this lengthy operation, it looked to me like all of those files were in the Repository. So I just added a label on the top level folder, and then I noticed that the add of all those files was actually waiting in the pending changeset list for a commit.

What's going on? Why so much time if those files weren't even sent to the repository, or were they?

If they were, what's going on now that I'm doing the commit?

I'm guessing that my label doesn't contain the files that are just now being committed?

I'd like to know what is happening where just for my own mental model. Much of my confusion is just because when the initial add took so long I forgot about the fact that it wasn't committed especially because I was seeing those added files in the main Vault window. So now I'm just trying to understand the relationship between what I see in the main Vault window and what is actually in the Repository, etc.

Thanks,
Mike

[jeremy_sg]

mlippert,

I've had another user complain of a large upload failing on his 2003 server, but the files appearing in both the repository and the pending change set. In his case, setting the "Connection timeout" from its default value of 120 to 7000. You can get to this setting by opening the IIS manager, right clicking on Web Sites\Default Web Site, and choosing Properties. The Web Site tab will have the setting that you should adjust.

[mlippert]

OK, well the commit finally finished, and what I see together with what you just said explains what was going on.

When I originally did the add, I accidentally specified the wrong folder to add everything too, and so I aborted that transaction, and did the add again to the correct location.

It didn't occur to me to look, but what was in my pending changelist was obviously the original aborted add, because now that I've committed it, I can see all of those folders and files in the wrong location as well as still being in the correct location.

That means that both transactions were doing the exact same thing, and it wasn't 2 halfs of the add process like I thought in my previous post.

Thanks,
Mike