Having a solid environment is an important prerequisite for well maintained SharePoint installation. Designing optimal installation requires planning in details. If the installation is not done properly, you can later on experience strange issues, performance issues or just both. The set or best practices I will mention below are built for the SharePoint on-premises, in the near future, I am planning to do the same best practices for SharePoint Online as well.

The biggest problem with the best practices is they are all over the place, you have official SharePoint best practices from the Microsoft, you have a lot of independent consultants and MVPs with recommendations so you need to spend quite a while to find relevant information.

I will separate SharePoint best practices into a few physical/virtual layers, so it is easier for you to understand on which layer you need to apply what best practices. This is important because I saw a dozen times that people who are in charge of SharePoint don’t have access to the SQL server, to the virtualization layer below the windows server and to the network. This is a way to go, but then different teams need to apply a different set of best practices to the different SharePoint components.

SharePoint Virtualization layer

In the nova days, the SharePoint is installed mostly as virtualized systems. I have seen SharePoint servers virtualized, but some bigger deployments keep even today SQL server on the bare metal. We will come to that later on. SharePoint most popular virtualization platform is VMware followed by the Hyper-V. 

For the virtualized environments the best practices are: 

• Do not use Hyper-V Dynamic Memory or VMware memory overcommit because it is not supported by the SharePoint Server platform
• Use VLANs to separate the traffic, use one VLAN for central admin, other for user sites because this will make your SharePoint more secure 
• Do not use Hyper-V or VMware Time Synchronization because sometimes SharePoint timer jobs can lead to unpredictable behavior 
• Do not use snapshots. Snapshots is not BACKUP! Using snapshots also can quite degrade performance of the virtualized machines. Snapshots can be used in TEST, DEV or UAT but not in production. Snapshots always trigger weird behaviors of the virtual machines that you are not always to detect from inside the virtualized machine because it can throw completely illogical errors 
• Jumbo frames on the network level are recommended 
• Some people recommend set page file manually. I do not recommend setting page files manually as in Windows Server 2012 R2 and better handles this better then the manual setting
• On the Hyper-V hosts set power plan to high performance. default balanced plan is always activated. This option allows you 15% higher throughput
• Configure windows server to best performance from default best appearance in the system settings

SharePoint SQL Server layer

The performance of SharePoint Server is heavily dependent on SQL Server. Poorly designed server, sitting on the poorly configured hardware (or virtualization layer) can lead to various performance problems in regards to SharePoint farm. The most important thing is DO NOT USE default SQL server configuration. It is not optimized for the SharePoint. 

Follow these rules to check the recommend SQL server best practices for the SharePoint: 

• use NTFS 64 KB allocation units instead of the 4 KB allocation units. You can save a 30% performance penalty by choosing the correct formatting option for your SQL Server machine. This is one of the most important settings to check most of the people don’t care or just overlook
• Prioritize the disks with different speeds in this order: 
  • 1. TempDB Data Files and Transaction Logs
  • 2. Content Database Transaction Logs
  • 3. Search databases
  • 4. Content Database Data Files
• Put the TempDB Data Files on the flash drives if possible by any means, not shared by the other volumes. Create separate LUN of separate physical disk
• DO NOT set the logs on the same drive as the content DB files again for performance reason 
• MAXDOP must be set to 1 for SharePoint to work normally. Period. 
• Restrict the memory consumption on the SQL server. DO not leave this setting to be managed by the SQL server
• DO NOT use the  auto create and auto update statistics on the SQL instance because is not supported
• DO NOT use default autogrowth. For example, try starting out with 256MB for your growth settings, and monitor how data is growing, set limit to be higher if needed. Setting the autogrowth setting too low will cause frequent database growth, which is not good for performance, but setting it too high will cause performance issues during the autogrowth (because it takes too long to complete and reserve the space). 
• Use the named instance 
• I’ve saw people for security change the default SQL port as well 
• Authentication should be the Windows authentication 
• The number of data files should correspond to the number of processor cores (minimum 4/maximum 8)
• The initial size of the LDF file should be set to 25% of the initial MDF initial size. Make sure that the LDF value can be divided by eight out of the MDF value
• set the initial size of the TempDB to 25% of the size of the largest content database
• Make sure your databases are backed up on regular intervals. I recommend:
  • Daily Full Backup of the content databases including the Consistency Check
  • Transaction Log Backups every 60 minutes
  • Weekly backup of system databases
• Use the SQL server aliases. This will ease your job in future when you need to migrate SQL server somewhere else
• Use SQL failover clusters where possible 
• You wouldn’t believe but #1 reason even today for SharePoint going offline is disk space on the SQL. MONITOR YOUR SQL SERVER DRIVES!

SharePoint Application/Web Front End layer

Now when we set the two underlying layers we need to make sure our SharePoint layer is configured according tot he best practices. I won’t recommend how many WFE/APP servers because that heavily depends on your environment. The simplest scenario would be 1WFE, 1APP and 1SQL server. Depending on your budget and the number of users you will support you can scale up the frontend servers, app server and the SQL servers as well. There are numerous of different scenarios so the best would be to search for architecture design of the SharePoint farm so you can find the optimal scenario. Also please feel free to contact me directly with your requirements, I will help you. 

• don’t use the SharePoint Configuration wizard :-) Use the PowerShell instead
• DO NOT use the same service account for everything. Use the different account for installation and configuration, for the Timer service, for the app pools, crawl and profile Sync. There is a great article by Vlad Catrinescu on what service account to use here. 
• DO NOT use more than 5k site collection per content database 
• Set quotas on the SharePoint Web Application Level
• Patch your SharePoint farms regularly. Patch the Windows servers, patch the SQL and the SharePoint as well. 
• change the default location of the ULS logs. SharePoint logs can generate quite a lot of data so using this on the system drive can decrease the performance of the whole SharePoint environment
• Disable Loopback check
• Enabling BLOB Cache in SharePoint. This is a popular way of improving performance of the SharePoint. The BLOB cache is a disk-based cache that stores binary large objects (BLOB’s) on the web server to reduce the load on the database server by avoiding unnecessary round trips to that server
• Enable Publishing Cache because can improve performance for users on SharePoint sites 

As you can see there are quite a lot of SharePoint best practices that you need to pay attention to. 

Do you have a setting that I have missed maybe? Let me know in the comments below on what settings you set on your SharePoint servers? and I will update the article!

BTW there is an application that will do all this checks automatically for you here. The biggest problem with the SharePoint best practices is there are to many of them, If you have few farms it can be quite consuming to perform the first check and regular checks. The SPDocKit will check your farm automatically for the SharePoint best practices and will alert your if your farm is not compliant. This is a great time saver!