When you work as a consultant or as a SharePoint administrator, there are many things that you need to set up to get the best SharePoint performance. Moreover, you need to be very careful in planning the infrastructure and testing.
Microsoft’s Best Practices have been published on their site and blogs, but also there are some great recommendations from MVPs and other SharePoint folks and communities, who are trying to squeeze the last bit of performance from SharePoint to get a better SharePoint system.
In general, the best practices are divided into best practices for performance, security and infrastructure planning. In this post, we will show you how some small changes to a configuration can greatly improve SharePoint stability, security and performance.
SharePoint farm layers As you all know, SharePoint 2013 is often virtualized. So, besides the SharePoint and SQL server configurations, you need to know all about your virtualization software and the underlying hardware. In this post, I will use Hyper-V as the virtualization platform, but some of the stuff is universal to other platforms. So let’s see how this looks for some example farm on the picture!
Before you even begin to install SharePoint, you need to start at the infrastructure layer and follow the best practices for it and then move up to the SQL server layer and at the end to the SharePoint layer.
This is often a part of the system that the average SharePoint admin is not in charge of, but when implementing SharePoint you also need to think about it. Even if your storage, network and server admins are doing their best to keep this part up and running, there are some special configurations that can help you to improve your SharePoint system.
These are just a few examples to show you how important it is to understand that even non SharePoint stuff can have a direct impact on SharePoint stability and performance. Beware that some of the recommendations might not apply to your environment, because almost every environment is unique.
You can see further details about some of the recommendations with a detailed explanation for a Hyper-V environment here.
SQL Server layer
In most cases, poor performance occurs because of a SQL Server misconfiguration. Using the default values for SQL Server is probably, in most cases, the worst configuration. SharePoint doesn’t support some configurations and it is best that SharePoint has its own dedicated SQL instance. Also SQL Server has rules for how it should be virtualized and you need to follow these rules and check what SharePoint requires from SQL.
There are numerous SQL recommendations that you need to follow to get the most from your SQL, and, in the end, your SharePoint server. Security is also an important factor and also needs to be carefully planned. Achieving high availability is critical for databases and you should have disaster recovery scenarios prepared and most importantly tested regularly.
You can read details of some SQL recommendations here.
SharePoint Application/WFE layer
SharePoint is the last layer in our stack. When we are setting everything up that SharePoint needs to work properly, we need to take decisions about the farm architecture. For your scenario, you need to make decisions on how many servers you need, how many will be APP or WFE servers, whether you need load balancers and other stuff.
After the initial design has been adopted, it is a good strategy to re-evaluate the whole design from time to time, especially if you see bottlenecks in some part of SharePoint. For example, if you see that the Search Service Application is slow, maybe it is time to add a couple of new servers to your farm for Search only. These are individual decisions that you will need to make based on your scenario.
The general strategy is to keep your SharePoint healthy, clean and speedy!
TechNet has a wiki page with lots of resources on this theme.
In this article, I have tried through some simple recommendations to show you how important it is to understand the big picture. Sometimes you will need to identify bottlenecks that are, maybe, not directly SharePoint’s fault, but are due to some connected services or underlying service that stops SharePoint from performing well. In most cases, it is difficult to track all of these recommendations for all of the above, so I’m pleased to be able to recommend the Documentation Toolkit for SharePoint, which has built-in Best Practices reports.
These reports will show you what you can do better within your farm. They will tell you a lot about your current setup and configuration and will save you some time. Finding the right recommendations and checking whether they have changed is time-consuming, so I believe that these reports will help you.
Managing and maintaining SharePoint is complicated, but is easier if you understand the best practices and which ones are relevant for your environment. There are a lot of resources regarding this online and I would definitely recommend that you regularly check Microsoft articles and follow SharePoint MVPs’ and consultants’ blogs because in them you can find a lot of really great tutorials and explanations about best practices.