As a SharePoint consultant, I have seen quite a few end-user complaints that SharePoint is slow in different organizations. The only thing which these slow environments reveal is poor planning and design flaws of overall SharePoint architecture.
In that context, getting proper requirement analysis from stakeholders, and managing the scope of that project are extremely crucial in order to have a successful SharePoint implementation and make end-users happy. In my 5 years experience on SharePoint administration and architecture designing, I have learned that planning of SharePoint is the key to complete user requirements.
This blog post is focused on better administration along with watching out for the primary bottlenecks and tools.
Let’s get started:
1. Planning for SharePoint Infrastructure - Hardware Specifications: Check out SharePoint 2016 hardware/software requirements.
Proper planning for hardware and supported infrastructure needs to be carefully done. SharePoint 2013 Server is RAM hungry. Therefore, many of the SharePoint performance issues are attributed to the lack of resources.
- Capacity Planning:
Is SharePoint Infrastructure designed according to Microsoft Hardware and Software minimum requirements?
This is one of the most important aspects where a SharePoint architect needs to talk to the infrastructure team.
Key design for SharePoint architecture includes:
i) Latency: Time between when a user clicks on browser and reposted back. This is something that the end-user complains about SharePoint being slow.
Tools:
>> IE Developer tools to check the response. (It’s extremely useful)
>> Fiddler
ii) Throughput: Number of requests that a server farm can process in a unit of time. Some common examples of low throughput conditions is when processors on the farm are not over-utilized. For e.g. if CPU usage during peak hours or load spikes consistently exceeds 80 percent, add more servers or redistribute services to the other farm servers, make sure there is sufficient memory on application and web servers to contain the complete cache, ensure that database servers are free of bottlenecks.
Tools:
>> Enable SharePoint Developer Dashboard.
>> SQL Server Logging Database
Below capacity planning is specifically for SharePoint 2013.
- Choosing Processors:
SharePoint Server 2013 is available only for 64-bit processors. Therefore more processors will enable us to serve greater demand.
- WFEs: In individual web servers will scale up as we add more cores.
- Application server: Application server processor capacity requirements differ depending on the role of the server and services it is running.
- Choosing Memory:
- Web Servers: Microsoft recommends you allocate at least 8 GB RAM on each web server and 16 GB for servers that have greater traffic or deployments with multiple application pools set up for isolation
- Application server: Application server processor capacity requirements differ depending on the role of the server and services it is running. Ideal application server should have minimum 4 cores (quad-cores) and recommended 8 cores (octa-cores)
- The memory requirement of database servers are tightly dependent on the database size.
- Choosing Network:
There is significant traffic in a farm across the web server tier, the application server tier and the database tier. The network can easily become a bottleneck under certain conditions like dealing with very large files or very high loads.
Web Servers and application servers should be configured to use at least two network interface cards (NICs): one NIC to handle end-user traffic and other for to handle inter-server communication.
- Choosing Disk and Storage:
We need to ensure at least 30 percent additional capacity on each disk, above our highest data estimate, to leave room for future growth.
The web and application servers have storage requirements also. In most of the production environments, Microsoft recommends that we allocate at least 200 GB disk space for OS and temp and 150GB for disk space for logs.
2. Optimize SQL Server for SharePoint:
The database is a common area where performance hits are most prevalent. SharePoint is database intensive, about 95 percent of SharePoint is stored in a SQL database: files, images, videos, pages, content, user profiles, etc. It’s important to have a happy and health SQL database running
- Tasks Manager on SQL Server: Check the services which are consuming too much RAM and CPU. We also need to configure I/O counters as well.
- Configure Model System Database Settings
- Increase auto growth settings (Use MB and not %)
- Recovery model should Full.
- Configure TempDB System Database settings
- Increase auto growth settings (Use MB not %)
- Recovery model should be Simple
- Max Degree of Parallelism
Set max degree of parallelism to 1 for instances of SQL Server that host SharePoint Databases, and it is to ensure that a single SQL Server process serves each request.
- Minimum Server Memory
Default is 2 Billon; way too much for SQL Server. Other applications may be slow because SQL Server is consuming maximum RAM available.
![]()
The following table gives RAM usage for SQL Server 2014.
| Server memory(GB) |
SQL Server Max Memory |
| 8 |
5012 |
| 12 |
8294 |
| 16 |
11571 |
| 24 |
19968 |
| 32 |
27136 |
| 64 |
55808 |
3. Optimize SharePoint:
The above points primarily dictate that "Hardware Requirement" and "Capacity Planning" are fundamental concepts and designed by the SharePoint architect, by gathering user requirements to provide a pilot SharePoint environment. Generally speaking, while setting SharePoint infrastructure and SQL server is quite easy to set up, the primary challenge arrives when more data is added to SharePoint lists/libraries and users keep complaining that SharePoint has become slow. The below are the reasons for slow SharePoint:
- Tasks Manager on servers: Check the services which are consuming too much RAM and CPU. Use PowerShell script the services which are consuming more RAM.
- Offload the SharePoint logs from C drive to other some drive on server.
SharePoints logs are usually on the drive it was installed on, and in most cases that’s the C drive of the server. It’s recommended to move these logs to another partition, and preferably different drives altogether.
- Go to Central Administration >> Monitoring >> Configure Diagnostic Logging.
- Note the top part, Event Throttling. This specifies what SharePoint will log. If any of these have been changed from default, they’ll be in bold. Your ideal settings for all of them are
- Least critical event to report to the event log: Information
- Least critical event to report to the trace log: Medium
- In the next section, Event Log Flood Protection, make sure that’s checked.
- And in Trace Log section, feel free to move the logs to a different drive to either free up space on the current drive or to a unique drive. You may limit the amount of days or space the logs use per your preference.
- Click OK.
- Web Parts:
- Large number of closed Web Parts, often on the home pages, will slow down a page. Every closed Web Part causes a small amount of processing overhead, and it can add up. To check this, add ?contents=1 to the page’s URL and remove any Web Parts which aren’t displayed. It can make a huge difference.
- Enable Developer Dashboard - Any custom developed web part or third party web pat that is slowing the page. Developer dashboard contains information about Web Parts, events, DB calls and a whole lot of nifty information.
- Large lists and libraries containing several thousand items can slow things down a lot too.
Optimize: Content Query Web Part, list view and metadata navigation and search
- Consider Warming up your SharePoint Site
Warming up the pages across your SharePoint site is a good idea for two reasons. Firstly, ASP.NET’s Just-In-Time compiler will often cause the first access of a site to be extremely slow compared to usual. Secondly, the caching techniques discussed previously only kick in once a page has been visited for the first time. By running a script or job to warm up the site you can avoid the ‘first hit’ performance lag associated with these issues. There are a number of sources of information regarding this topic but one such article that seems to collate a lot of them is Wahid Saleemi’s Roundup: SharePoint Warm-Up Scripts.
- Make Use of SharePoint’s Built-In Caching Functionality
- Distributed Cache Service Application:
SharePoint Distributed cache service is an automatic service. However, if we configure to a dedicated distributed cache service you may face some challenges.
I had earlier written a detailed blog specifically about the challenges with Distributed Cache service.
I had a chance to work an outsourced (inexperienced) vendor and they claimed that SharePoint server on pre-release were slow servers. As a matter of fact, vendors has absolutely no idea how to solve the issue. It is a migration project from SharePoint 2010 to SharePoint 2013 and the SharePoint 2010 had a heavily custom site and branding.
This how I found the root cause.
- Hardware specifications: I checked both the staging environment and pre-release environment hardware specs. There were absolutely identical. So it's ruled out.
- SQL Server: SQL server settings, parameters and assigned memory were identical. So it's ruled out.
- Firewall: The Firewall rules were verified for both the environments there were identical. So it's ruled out.
- Search settings: Content Sources were configured as incremental. Continuous crawl was configured. So it's ruled out.
- Distributed cache settings: Service is started status on App server. It's not enabled on WEB server.
- Developer Dashboard: I turned on Developer dashboard both the staging and pre-release environments to check the page performance. I noticed staging environment Internet Explorer developer tools showed page load 1.5 seconds but whereas pre-release environment showed 6 seconds for the custom branding site.
I checked if any error on the ULS tab for developer dashboard. I couldn't find any error that showed whatsoever that jump of execution of 6 seconds.
ULS viewer didn't give error that gives any indication of 6 sec jump. However, I know it could be of Distributed Cache service. What I know is that there is some wrong in this pre-release environment.
- New Web Application: To narrow down this issue, I created a Web application using team template. I asked vendor if they have code related My Site or Distributed cache. They do have some custom code related to My Site. I removed their solution.
Turn off and turn on the Distributed cache sever. Restarted the timer service on App and web server. The new Web application's site loads within 1 second.
It tuned out that issue was custom code made web application non performant and vendor admitted that it was their code that had an issue.
- Search Service Application:
One of the sluggish performances could be from Search service application. Following the tips to improve:
- Ensure that we have SharePoint 2013 March patch.
- Reduce the Search crawl time interval.
- Major change could be change the Search’s server’s noderunner. Make a copy of noderunner.exe.config (C:\Program Files\Microsoft Office Servers\15.0\Search\Runtime\1.0\noderunner.exe.config)
The default is Maximum. We can adjust the search performance by setting PartlyReduced or Reduced
Set-SPEnterpriseSearchService -PerformanceLevel Reduced
I hope this blog helps and please comment if this blog post is helpful.