Slow on Multiprocessor machine

[jclausius]

CityOne - I've examined your logs.

There are some discrepencies, but nothing that points to any obvious problems.

I did notice while the quad machine was running, there was other activity from other history queries within the log file. This could possibly explain some of the timing differences. If the database is executing history queries as well as streaming out BLOB info, that would explain slower times.

I also noted the manner in which the requests came in were ordered differently in the two requests. This might explain for some of the timings. You may want to reset your Vault client side cache for each test to see if that evens the test timings. It could be when the Vault Server retrieves the request for the file BLOBs, one test is accessing them based by their primary key clustered order, and the other is not. That would also explain some of the timing differences.

Also, since the quad machine is hosting both Vault Server and SQL Server there could be some differences as the OS has to use resources for both processes, context switch between Vault and SQL Server, where the other enviornment each OS only has to only deal with the individual resources for its own process.

[cityone]

That explains why we had the problem of running multiple Worker Processes for VaultAppPool. In this case, I think the error message when checking in multiple files was that the transaction failed and the files failed to checkin.

I still have not got the answer as to whether Vault Server runs slower on a MP machine compare with a single processor machine. Do you have some result for that comparsion?

Secondly, is it possible to set up two Vault Servers pointing to the same VaultDB? We want to setup another Vault Server so load can be spread.

BTW, I sent our vaultlog to 'Linda Bauer'. Have you got it? Anything unusual?

Thanks!

[jclausius]

I still have not got the answer as to whether Vault Server runs slower on a MP machine compare with a single processor machine. Do you have some result for that comparsion?

No I do not. This would be the first time any customer has brought up the issue, and internally we have no data for comparison. Our internal Q/A and testing include running Vault on an SMP machine, but there is no benchmark for performance comparisons as there is no similar hardware to benchmark against.

Secondly, is it possible to set up two Vault Servers pointing to the same VaultDB? We want to setup another Vault Server so load can be spread.

As long as the multiple servers only work on DIFFERENT repositories, this is a supported configuration. In other words, Repository 1 must only be served by Vault Server 1. Repository 2 can only be served by Vault Server 2.

Within a vault.config you will find an "AllowRepositories" xml element. You can place a comma delimitted list in this element to configure the Vault Server to only serve up a given repository.

For example, if you have 5 repositories, you'll need to know their repository ids (SELECT repid, name FROM sgvault.dbo.tblrepositories). Using this info, you would configure Vault Server 1 with <AllowRepositories>1,3,4</AllowRepositories> and Vault Server 2 with <AllowRepositories>2,5</AllowRepositories>. All 5 repositories would be covered 1, 3, and 4 by the first server and 2 and 5 by the second server.

BTW, I sent our vaultlog to 'Linda Bauer'. Have you got it? Anything unusual?

Yes. My previous post discussed this. There were some things that would account for discrepencies in timings (things like history queries being run by other processes during the first test's get, and the ordering of file requests).

[tomt84]

Do you happen to have Intel based chips? If so, have you turned OFF hyper threading?

In our testing here, hyper-threading is off due to some problem we've encountered with SQL Server and the Vault stored procedures.

Apologies for resurrecting this, but could this possibly be a contributory factor for the issues in this thread of ours from a while back?

We've still not found/fixed that issue.

Regards
Tom

[jclausius]

Are you referring to just deleting the folder within VS 2005? I don't think that is the problem here.

FWIW, this bug has been fixed within the Vault 3.5.2 release scheduled for release in Jan/Feb 2007.