Prior to upgrading my machine to Windows 8, I was forced to use VMware Workstations 8 & 9 for development within a virtual environment.
My virtual environment within VMware Workstation 9 was:
- Windows Server 2008R2
- Visual Studio 2012
- SharePoint 2013
- SQL Standard 2012
- 16 GB RAM
- 4 Proc’s
When debugging SharePoint 2013 server-side code, all requests to SharePoint through the w3wp.exe process is extremely slow. Furthermore, stepping through code becomes very sluggish. Additionally, while debugging 2013, the Virtual Studio Remote Debugging Monitor process eats up anywhere between 20-30% of the CPU resources.
As you can see my machine’s resources are quite large; and, the VM operates fine otherwise. Again, only while debugging SharePoint does the w3wp.exe process crawls.
A few things I’ve noticed…
When debugging a solution in SharePoint 2013 and deploying from Visual Studio (F5), if SharePoint’s AppPool has cycled down, then the Visual Studio Remote Debugger spikes to 20%+ of processor resources and SharePoint very seldom loads.
Prior to deploying the solution, I open the local SharePoint instance in my browser. This starts the AppPool process. Once SharePoint loads in the browser, I return to Visual Studio and deploy the solution. SharePoint now comes up without a hitch.
The combination of the two scenarios is also the same…if I’ve worked in Visual Studio for at least 20 mins without deploying/reloading SharePoint (enough for the default recycle timeout of the AppPool), then the debugger takes forever. However, as long as I continue to deploy my solution and/or refresh SharePoint in the browser to keep the AppPool from recycling, I have no issues.
Therefore, I’ve increased the default AppPool recycling timeout from 20 mins to 60 minutes just to be safe and most productive. Unfortunately, this doesn’t help when I’m deploying solutions that have to release code to the GAC and the AppPool gets recycled with deployment.
Ultimately, I think the issue lies somewhere in the cycling of the AppPool, but that’s just my humble opinion.
Click here for the MSDN forums article.