I’ve been working with SharePoint for quite a few years now in many different environments using both on-premises and Cloud-based solutions and a constant remains : SharePoint development environments are slow…
Here are a few tips that can help to speed up your dev machines.
- 1) Remove all the unnecessary service applications that were created if you downloaded a preconfigured VM or did provision the default settings with the configuration wizard. I use to keep only the User Profiles, Search, Managed Metadata, State Service, BCS, Secure Store Service & App Management services running.
- 2) Disable Sandboxed Code Service (it’s not a service application). Since Sandboxed are deprecated, you’ll likely not going to use them anymore so you’d better turn off the service.
- 3) Unless you specifically develop search based applications and require some constant indexing, turn off Continuous Crawl. Search is very greedy when it comes to CPU & RAM and usually Continous Crawl isn’t required for development environment. If you don’t use Search at all, you might consider removing the service application or stop it via PowerShell. If you need to use the Search Service Application, you might consider set it to a Reduced configuration via PowerShell (Set-SPEnterpriseSearchService -PerformanceLevel Reduced).
- 4) Revoke CLR check. A full explanation can be found on Joel’s blog at http://joelblogs.co.uk/2011/09/20/certificate-revocation-list-check-and-sharepoint-2010-without-an-internet-connection/. It’s for 2010 but it also applies to 2013. This step is absolutely required when your dev environment isn’t connected to Internet. It will speed up PowerShell, STS & post-application pool recycling operations.
- 5) Make sure to disable health & usage data collection. This consumes resources but it also consumes a lot of hard-disk space. In most cases, this is absolutely not necessary in a development environment
- 6) Depending on your hardware resources such as the amount of available RAM, you might consider to use a separate VM to host SQL Server and make sure that this is hosted on a fast hard-disk. I personally use SSD for my own environments. Within the enterprise, you should discuss with your admins to see what’s best. Note that if your SQL isn’t hosted on a fast drive, performance will probably not improve but you’ll have more RAM dedicated to pure SharePoint processes.
- 7) In case you’re really in trouble with your environment, you might consider to stop the SharePoint Timer Service. I don’t recommend to stop it by default but in situations where your system is under high stress, it can perfectly be done on a development environment. If you have to deploy/retract solutions, you can use Install/Uninstall-SPSolution with the -local flag that will directly deploy/retract the solution locally on the running server. When your system is again under control, you should restart the Timer Service. An alternative to stopping completely this service consists in disabling some well identified Timer Jobs., especially those that have a Minutes schedule
- 8) Either, turn off diagnostic logging by stopping the SharePoint Tracing Service or reset all the categories to None or Critical in order to log nothing or only critical issues. This will not only have a positive impact on performance but will also spare some disk space. Moreover, when you’ll try to debug something, you’ll switch those categories to Verbose only during the debugging session
- 9) If you can afford, use SharePoint Foundation instead of SharePoint Server. It’s way lighter & faster. If you use SharePoint Foundation, you can omit all the steps described so far except the CLR check.
- 10) This one isn’t configuration related, it’s more bound to the attitude of the developer. You should consider to minimize the amount of farm solution deployments. So, stop using F5 and/or deploy with Visual Studio. Whenever you deploy a FARM solution, one or more application pools get recycled and the first hit following a recycling is very slow.
Depending on what you develop, there are often many pieces of code that can be tested from a non SharePoint context such as a Console Application. So, during the development phase, you might consider to test some pieces of code within Console Applications which require no deployment and move this code later within the actual SharePoint Solution. It know that this might not sound very professional to work like that but it can save you a lot of time.Of course, this does not apply to Apps that make use of CSOM/JSOM and don’t require application pools to be recycled, thus no post apppool recycling pain.
Of course, all of the above can or cannot be done according to your development scenario. I just observed during the past 8 years that most of the developers use fully-configured VM (also within the enterprise) and only use half of it, if you already follow the steps described above, you should really notice a performance difference.