We have a vs.net solution that includes 6 projects - one large web project (2,500 files) and 5 libraries totalling about 400 source files. Running SOS 4.1.2 on the client, 4.0.0 on the server.
Performance on a Get Latest Version is quite adequate - completes in about 3-4 minutes. However the initial opening of the solution takes about 30 minutes.
I have run various performance counters against both the server and client systems to ascertain what is occurring. There is very little load on the SOS Server - either disk access or processor. Network activity is much lower than what our network can handle - less than half a dozen packets/sec over a connection with only 9ms latency.
The heavy work is being done on the client system. Devenv.exe is using close to 100% of one processor on a dual 2.8Ghz system. Monitoring the performance counter System ...File Data Operations/sec shows 50,000+ file data operations per second during most of this time.
Further review with Sysinternals Filemon.exe shows that the vast majority of these file operations are against database1.sos - thousands of tiny (2-20 byte) operations per second, the vast majority of which are write operations (FASTIO_CHECK_IF_POSSIBLE, FASTIO_WRITE, IRP_MJ_WRITE). Just watching the database1.sos file, in windows explorer I see it jumping around in size - down to about 100KB, up to 500KB and anyplace in between.
Antivirus real time scanning is turned off on this system.
It seems that access to the local SOS cache in database1.sos is the issue. Any ideas on how solution load experience can be improved?
Slow load of large vs.net solution
Moderator: SourceGear
Solution opening also incredibly slow
I too am having the exact same problem. We also have a solution that contains a web project with about 2300 files, and then 3 class libraries totalling about 600 files.
Getting latest over a VPN is really fast (have written a batch file to get latest of all our development branches) however when opening those projects within Visual Studio it takes forever to load. Once it has eventually loaded, checking in/out is fine. Alternatively should I not have any network connectivity and choose to open the project disconnected - it opens instantly (obviously as all the code is local).
Does opening a solution/project that is source controlled automatically run some sort of file verification process - or even get latest?
Perhaps there is some way to turn this off?
Any help on this would be greatly appreciated - as it currently means that I have to wait a good 1/2 hour whilst opening my solutions each morning..
Getting latest over a VPN is really fast (have written a batch file to get latest of all our development branches) however when opening those projects within Visual Studio it takes forever to load. Once it has eventually loaded, checking in/out is fine. Alternatively should I not have any network connectivity and choose to open the project disconnected - it opens instantly (obviously as all the code is local).
Does opening a solution/project that is source controlled automatically run some sort of file verification process - or even get latest?
Perhaps there is some way to turn this off?
Any help on this would be greatly appreciated - as it currently means that I have to wait a good 1/2 hour whilst opening my solutions each morning..
It's not unusual for a Visual Studio project with 2900 files to take some time to open. Opening the solution may trigger something like a file list refresh, with a check against the database cache file, and possibly multiple logins to the SOS Server.Does opening a solution/project that is source controlled automatically run some sort of file verification process - or even get latest?
I'll consult with our SOS developer for a more definitive answer. That person is out of the office for a few days, so it will be later this week.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
This is not simply an issue of a large solution taking a long time to load. This same solution that takes 30 minutes to load with SOS as the SCC provider loads in 3-5 minutes using native VSS.
The situation reverses when performing a GLV for the full solution - in that context, SOS is quite quick while VSS takes 20-30 minutes.
The situation reverses when performing a GLV for the full solution - in that context, SOS is quite quick while VSS takes 20-30 minutes.
Yes, I did get more information, but it just confirmed my earlier post.
Visual Studio must go through many checks when you do an "open from source control," and this takes time. If you're working on same LAN as the VSS database, and using integration with VSS, this is faster.
Since SOS is a client-server, remote application, open from source control takes longer. Also, SOS does not communicate directly with the VSS database -- the SOS Server communicates throught the VSS automation component, which is not as fast.
Visual Studio must go through many checks when you do an "open from source control," and this takes time. If you're working on same LAN as the VSS database, and using integration with VSS, this is faster.
Since SOS is a client-server, remote application, open from source control takes longer. Also, SOS does not communicate directly with the VSS database -- the SOS Server communicates throught the VSS automation component, which is not as fast.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
Understandably it is going to take some time if you do an "open from Source Control" as it has to download all the source code from the remote server. I am referring to simply opening a solution that you have already opened from source control (i.e. already have the source code on local disk) and having to wait an extended amount of time.
With regards to working on a LAN - even when I was on the same LAN as the source code it still took forever to open. I currently have 2 colleagues that still work on the same LAN as the sourcesafe server (using sourceoffsite to connect to the sourcesafe database on that same server).
If we had to consider any of your other products, would these problems be alleviated?
With regards to working on a LAN - even when I was on the same LAN as the source code it still took forever to open. I currently have 2 colleagues that still work on the same LAN as the sourcesafe server (using sourceoffsite to connect to the sourcesafe database on that same server).
If we had to consider any of your other products, would these problems be alleviated?
There seems to be a misconception on the part of Sourcegear that I am running against VSS/SOS on a LAN. This is not the case. I am running over a VPN via a good quality Internet connection (Verizon FIOS) but the round trip time for file operations such as those used by VSS is substantially more than 10 times what it would be on a local LAN.
Also, I am not performing and "Open from source control". I am simply starting up vs.net and opening a solution. No local project files are updated during this process - newer versions checked in on the server are not being pulled to the client.
Please review my original post - network traffic or load on SOS server / its access to the VSS files has virutally nothing to do with the slowness of the load.
All the activity is on the local system which is furiously making 50,000+ small writes per second to the LOCAL SOS database1.sos. When I enable logging on the SOS server, it indicates it is handling each request typically in 100 milliseconds. But there is a gap of 1 to 3 seconds between each request to the server - a period during which client side activity proceeds furiously.
SOS is able to perform a GLV for the entire solution in little more than 10% of the time it takes to open the solution in the first place. Surely there is not more access to the source control when merely opening the solution (may need to check whether file in source control) than performing a GLV (for each file, determine compare local version to source control version + download where source control version newer).
Also, I am not performing and "Open from source control". I am simply starting up vs.net and opening a solution. No local project files are updated during this process - newer versions checked in on the server are not being pulled to the client.
Please review my original post - network traffic or load on SOS server / its access to the VSS files has virutally nothing to do with the slowness of the load.
All the activity is on the local system which is furiously making 50,000+ small writes per second to the LOCAL SOS database1.sos. When I enable logging on the SOS server, it indicates it is handling each request typically in 100 milliseconds. But there is a gap of 1 to 3 seconds between each request to the server - a period during which client side activity proceeds furiously.
SOS is able to perform a GLV for the entire solution in little more than 10% of the time it takes to open the solution in the first place. Surely there is not more access to the source control when merely opening the solution (may need to check whether file in source control) than performing a GLV (for each file, determine compare local version to source control version + download where source control version newer).
I should have said "open a source-controlled project," rather than "open from source control."
If you compare opening a source controlled project with VSS over the Internet with SOS over the Internet, is SOS still faster?
Due to the architecture of SOS and the interaction between Visual Studio and source control, opening a a project can take time. Part of it is due to writing to the cache file, as you have observed. It's like a refresh operation, where the file lists are all being written to databaseX.sos file. Usually in the GUI client, you access only one project at a time, but in the IDE the entire project is refreshed. User have asked about bypassing this, but without the client side cache, SOS operations would be no faster than VSS over the Internet.
We'll continue to investigate ways to optimize SOS. Thanks for your feedback.
If you compare opening a source controlled project with VSS over the Internet with SOS over the Internet, is SOS still faster?
Due to the architecture of SOS and the interaction between Visual Studio and source control, opening a a project can take time. Part of it is due to writing to the cache file, as you have observed. It's like a refresh operation, where the file lists are all being written to databaseX.sos file. Usually in the GUI client, you access only one project at a time, but in the IDE the entire project is refreshed. User have asked about bypassing this, but without the client side cache, SOS operations would be no faster than VSS over the Internet.
We'll continue to investigate ways to optimize SOS. Thanks for your feedback.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
The opening of the same source controlled solution is much faster using native VSS than using SOS.
Using native VSS over the Internet the solution takes 3-5 minutes to open. With SOS over the same connection it takes 25-30 minutes.
Doing a get latest version at the level of the solution, these numbers are reversed. SOS takes less than 4 minutes, while VSS takes about 25 minutes.
It is this fact that SOS is able to do the GLV much faster than native VSS that makes me wonder why the opening of the solution should be so much slower with SOS.
Using native VSS over the Internet the solution takes 3-5 minutes to open. With SOS over the same connection it takes 25-30 minutes.
Doing a get latest version at the level of the solution, these numbers are reversed. SOS takes less than 4 minutes, while VSS takes about 25 minutes.
It is this fact that SOS is able to do the GLV much faster than native VSS that makes me wonder why the opening of the solution should be so much slower with SOS.