Slow...can we bypass the web service?

[neal007]

Welp, thank you for the rapid replies and I did update the settings. I also disabled index server as the site was also defaulted to be indexed in IIS. So with all the changes, I'll keep an eye on it and let you know if I see any improvements.

Sorry for the shift in topic, I'll sit on my hands and be quiet now!

[neal007]

LOL, but one more thing, you telling me I can't connect to SQL Server remotely? What's the diff?

Okay, now I'm being quiet!

[jeremymc]

I just have to chime in here... All of my experience so far has shown that Vault is much, much faster than VSS, especially when using it through the VS.NET IDE integration. For example, my company has a solution with 30 projects in it (don't ask), which used to take 30 minutes *just to open* in VS.NET connected to VSS. It now only takes somewhere around one or two minutes connected to Vault.

I agree with Eric on the web services issue. I highly doubt that it is the bottleneck. It might be argued that they could have used .NET remoting, but hey if it works, it works.

[neal007]

Okay, so this morning, I get up and give it a shot. Also keep in mind I rebooted the Windows 2003 server hosting Vault. I think the delay I'm seeing is actually the ASP.NET application (Vault) recompiling prior to returning data. Like I said in a previous post, I think this also occurs as a asp.net application "shuts down" after a certain amount of idle time which it will then have to recompile (I think) and this is the delay I am seeing. Once I have used Vault, the subsequent uses are fast and acceptable.

Just the nature of it being a .NET application I s'pose! (connecting directly to SQL Server of course would eliminate this, but again, beyond the scope, not a redesign issue, just a performance related issue dealing with asp.net).

Thanks, case closed, all is fine and all the settings have been updated per your responsive replies! Much appreciated! Great job and I'm happy to be using Vault!

[sterwill]

Because of the stateless nature of web services applications, the Vault server has to do some of its own caching so repository structure data is around when new clients need it. Restarting IIS (specifically, recycling the ASP.NET worker process) defeats all this caching, and will cause Vault to have to refill its structure cache the next time someone connects (causing long login times). Windows 2003 Server and IIS 6 have a "feature" that recycles the worker process every 120 minutes (according to this devx.com article). This should be disabled for servers running Vault, as it will cause terrible performance problems with medium to large repositories.

[jclausius]

Subsequent use is much faster.

One quick thing to note... Vault is a .Net application. Unfortunately, the integration within Visual Studio is standard unmanaged code using straight DLL calls through MSSCCI. In order to accomodate this, the Vault IDE component has to run its own little sandbox version of .Net to map the VS.Net unmanaged calls in and out of Vault's managed interface.

Its possible the initial start up time you see is related to the fact that the .Net CLR will be initially loaded up by the Vault IDE client.