It is important to implement a highly available as well as scalable SharePoint 2013 platform and avoid some of the known pitfalls that degrade its performance, such as the following:
- Having all SharePoint services in the “default” service group
- Having JavaScript that has not been optimized or deployed in a best practices manner
- Procuring or having inadequate hardware
- Not paying enough time and attention to SQL Server’s configuration and its optimization
- Not providing the proper tools to allow for monitoring and reviewing the underlying server logs
If you are experiencing performance issues, it is key to first attempt to perform exercises such as load testing in a similar or replicated environment, as well as reviewing the IIS logs, the server’s performance, and latency for web, service, and SQL servers. There are some obvious metrics that are sometimes overlooked, such as memory, RPS, and the CPU’s statistics.
There are some major updates or architectural considerations in relation to SharePoint 2013, such as discouraging dedicated service farms that end up increasing server count as well as overall maintenance requirements.
It is also important to use as few application pools as possible in SharePoint 2013 because each application pool takes up memory and resources, and it is better to share these resources to avoid some of the caching errors that have come up in many enterprise-wide farms.
There is also a recommendation for one web application as well as one corresponding zone as well as using host-named site collections that allow for reduced resource consumption and much better scalability. You are always able to have multiple host names in regard to secure site access (SSA).
SharePoint 2013’s Search and Scalability Recommendations
SharePoint 2013’s search, which now includes fast search, has very different metrics involved in the scalability of search. For example, for every 10 million items, there is a scaling recommendation to add an index partition.
With 20 million items, the scaling recommendation is to add a new crawl database, and with 30 million items, it is recommended to go with a dedicated search farm. I have also seen some great results when providing a dedicated host for crawling on the crawling target server.
Your search will always function at a higher level when it is originally architected with best practices in mind with defined targets and proper logical and physical architecture.
SharePoint 2013’s SQL Server 2012 Scalability Recommendations
There are a lot of similarities in recommendations from past versions of SharePoint. It is key to ensure that you always use SQL aliases whenever possible because this makes later migrations or database moves much easier and can save 100 or more hours of rework if those changes are ever needed.
There are several candidates for aliases, and if you begin with one SQL Server instance and three aliases, you will have the option to scale and later move any highly used databases into a dedicated SQL node.
SQL Server 2012 R2 comes with new AlwaysOn for redundancy capabilities, which is native in SQL Server 2014. This does require Windows Server Failover Clustering (WSFC).
