Are there any suggested settings you have for SQL Server and IIS to increase Vault performance? We have 50-60 users hitting it during the day and are experiencing severe slowdowns and some blocking as well (where the client hangs getting info from the repository). It's running on a dual Xeon server-class machine, so the hardware shouldn't be that much of an issue. I actually had to reboot the machine, b/c I wasn't sure what else to do to quickly fix the blocks.
One of the errors I've seen in the debug log is "Timeout expired. The timeout period expired prior to obtaining a connection from the pool."
Also, what's the largest set of concurrent users it's been tested against?
Thanks,
Joel
Vault blocking connections under heavy load
Moderator: SourceGear
joel:
i would recommend upgrading to vault 2.0 as soon as you can fit it within your schedule. we fixed a number of concurrency issues in the 2.0 release, which should improve your overall performance.
if you do happen to upgrade, and are still experiencing blocking issues, please let us know, asap.
one thing to note. the vault server is written to synchronize any transaction which modifies the source tree. so, if all 50 of your users are using the same repository, and 35 of them all check in a change within the same time frame, they will be queued up and processed in the order they're received.
to relieve this problem, unless you need to "share" code within the same repository, i'd recommend creating multiple repositories within the entire vault database. there is less contention for repository resources.
as for the number of users, i've personally talked to companies with up to 100 vault users on one server.
i would recommend upgrading to vault 2.0 as soon as you can fit it within your schedule. we fixed a number of concurrency issues in the 2.0 release, which should improve your overall performance.
if you do happen to upgrade, and are still experiencing blocking issues, please let us know, asap.
one thing to note. the vault server is written to synchronize any transaction which modifies the source tree. so, if all 50 of your users are using the same repository, and 35 of them all check in a change within the same time frame, they will be queued up and processed in the order they're received.
to relieve this problem, unless you need to "share" code within the same repository, i'd recommend creating multiple repositories within the entire vault database. there is less contention for repository resources.
as for the number of users, i've personally talked to companies with up to 100 vault users on one server.
Jeff Clausius
SourceGear
SourceGear
After testing Vault 2.0, we're still running into some concurrency issues. Namely, when a user does a large branch operation (which we often do, since we use merge trees to support concurrent development) and then another user does a checkout, the branch blocks the checkout the entire time til it's done. Not surprising, considering your comment on synchronization.
However, we'd still like to know if there's anything we can do to tune the performance, so users don't experience significant wait times. For instance:
1) Will deploying IIS and SQL on separate servers help?
2) Can large mutates be reduced to sub-minute and moderate ops be reduced to seconds w/o splitting our current repository? Our current repositories (we have 5) range from 1-4 gigs.
3) What were the specs on the 100-user shop's server (so we can compare with ours)?
Thanks,
Joel
However, we'd still like to know if there's anything we can do to tune the performance, so users don't experience significant wait times. For instance:
1) Will deploying IIS and SQL on separate servers help?
2) Can large mutates be reduced to sub-minute and moderate ops be reduced to seconds w/o splitting our current repository? Our current repositories (we have 5) range from 1-4 gigs.
3) What were the specs on the 100-user shop's server (so we can compare with ours)?
Thanks,
Joel
jclausius wrote:joel:
i would recommend upgrading to vault 2.0 as soon as you can fit it within your schedule. we fixed a number of concurrency issues in the 2.0 release, which should improve your overall performance.
if you do happen to upgrade, and are still experiencing blocking issues, please let us know, asap.
one thing to note. the vault server is written to synchronize any transaction which modifies the source tree. so, if all 50 of your users are using the same repository, and 35 of them all check in a change within the same time frame, they will be queued up and processed in the order they're received.
to relieve this problem, unless you need to "share" code within the same repository, i'd recommend creating multiple repositories within the entire vault database. there is less contention for repository resources.
as for the number of users, i've personally talked to companies with up to 100 vault users on one server.
it depends on how much memory is in your current server. however, i don't believe this will help your situation.1) Will deploying IIS and SQL on separate servers help?
i'll log a request for specific performance improvements around branch and snapshot. if the lock time can be reduced, your concurrency will go up.2) Can large mutates be reduced to sub-minute and moderate ops be reduced to seconds w/o splitting our current repository? Our current repositories (we have 5) range from 1-4 gigs.
additionally, i'll log another customer feature request to find a way to grant a checkout without obtaining a lock on the tree. currently a tree must be obtained to see if 1) the file exists, and 2) if security is on, the user has rights to that specific folder. i imagine this would solve most of the issues you are seeing.
are you talking about hardware specs. i didn't get exact information, but i was told they were looking to spend around $20,000 on a 4-way xeon server w/ some sort of multiple raid array.3) What were the specs on the 100-user shop's server (so we can compare with ours)?
Jeff Clausius
SourceGear
SourceGear
Does SourceGear offer consulting? Such as to perhaps fix this locking issue for us? Right now, we're still experiencing unacceptable performance with users waiting on checkins and merges that should take at most a minute or two.
I'm curious as to what larger shops (we have 55+ developers) are doing to avoid this problem, as it probably gets worse as more users are added. Are their settings for IIS or SQL different than the defaults? Our current machine is a dual Xeon processor with 2.5 gigs RAM and we're going to a quad Xeon processor with 4 gigs.
Thanks,
Joel
I'm curious as to what larger shops (we have 55+ developers) are doing to avoid this problem, as it probably gets worse as more users are added. Are their settings for IIS or SQL different than the defaults? Our current machine is a dual Xeon processor with 2.5 gigs RAM and we're going to a quad Xeon processor with 4 gigs.
Thanks,
Joel
jclausius wrote:it depends on how much memory is in your current server. however, i don't believe this will help your situation.1) Will deploying IIS and SQL on separate servers help?
i'll log a request for specific performance improvements around branch and snapshot. if the lock time can be reduced, your concurrency will go up.2) Can large mutates be reduced to sub-minute and moderate ops be reduced to seconds w/o splitting our current repository? Our current repositories (we have 5) range from 1-4 gigs.
additionally, i'll log another customer feature request to find a way to grant a checkout without obtaining a lock on the tree. currently a tree must be obtained to see if 1) the file exists, and 2) if security is on, the user has rights to that specific folder. i imagine this would solve most of the issues you are seeing.
are you talking about hardware specs. i didn't get exact information, but i was told they were looking to spend around $20,000 on a 4-way xeon server w/ some sort of multiple raid array.3) What were the specs on the 100-user shop's server (so we can compare with ours)?