Information Required Resolving SharePoint 2013 Performance Issues

The main goal of managing SharePoint Farm performance is to establish and maintain a system that meets the organization's latency, throughput, data scale and reliability targets. To resolve performance issues in SharePoint 2013, we need to gather the following information in the SharePoint Farm, both at the hardware and application level.

1. The following are the details for each of the web servers.

• Processor(s): Be sure that the processors on Farm servers are not over-utilized.
  
  
• RAM: Be sure that there is sufficient memory on application servers and Web servers to contain the complete cache. Else there would be additional trips to the database to serve requests for un-cached content and throughput will decrease.
  
  
• Operating system.
  
  
• Size of the SharePoint drive.
  
  
• Number of network adapters.
  
  
• Network adapter speed.
  
  
• Authentication.
  
  
• Load balancer type: Resource-intensive services and features can be directed to dedicated servers. Load balancer can direct feature-specific traffic to a Web server dedicated to specific features or services.
  
  
• Services running locally: Features, services and configuration parameters that are not optimized delay the processing of requests and impact latency for both remote and local clients.
  
  
• Timer Jobs: For better performance, schedule resource-intensive timer jobs and administrative tasks during off-peak hours.

2. The following are the details for each of the database servers:

• Processor(s)
• RAM
• Operating system
• Storage and geometry
• Number of network adapters
• Network adapter speed
• Authentication
• Software version

We need to ensure that database servers are free of bottlenecks. More disks need to be added if total available disk IOPS are insufficient to support peak demand. This will redistribute databases to underutilized disks and increase the throughput.

3. Topology and Configuration

Search Architecture, Services Distribution, Database sizing, data architecture and sufficient database server hardware are all very important to an optimal SharePoint solution. Content databases should be sized depending on limits guidance. They should be distributed across physical disks so that requests are not queued due to disk overutilization. Distribution and sizing helps database servers to support peak loads and unexpected spikes without exceeding resource utilization thresholds.

4. CPU Utilization for each server

For example, if CPU usage during peak hours or load spikes consistently exceeds 80 percent, add more servers or redistribute services to other Farm Servers.

5. External WCF Calls

These calls are dependent on the other system to return data within a specific time. Latency and throughput are both affected by any custom code or external calls.

6. Workflows

Long-running workflows and workflows that are not designed and tested properly can cause a huge bottleneck in SharePoint performance. Resource utilization is dependent on the complexity of the workflows and the total number of events they handle. In SharePoint 2013, we can run both SharePoint 2010 workflows and the new SharePoint 2013 workflows. We can isolate the workflow timer service to ensure latency does not affect the end-user and that workflow operations are not delayed.

7. MySites and Social Computing

The following MySites and Social Computing details are required in case there are issues with these areas:

• Number of user profiles.
• Average number of memberships / user.
• Average number of direct reports / user.
• Average number of colleagues / user.
• Number of total profile properties.
• Number of multivalue properties.
• Number of audiences.
• Number of MySites.
• Number of blog sites.
• Total number of events in activity feed.
• Number of social tags/ratings.
  
  These details will help sizing the database and memory required for Mysites and Social Computing.

8. Application detail level

At the application detail level we need to get a peek at of each application's transaction mix for which we are solving performance issues. An example is as shown in the following:

Feature or Service	Operation	Read/write	Percentage of mix
ECM	Get static files	r	8.93%
	View home page	r	1.52%
Microsoft InfoPath	Display/Edit upsize list item and new forms	r	0.32%
	Download file by using "Save as"	r	1.39%
Microsoft OneNote 2010	Open Microsoft Office OneNote 2007 file	r	13.04%
Search	Search through OSSSearch.aspx or SearchCenter	r	4.11%
Workflow	Start autostart workflow	w	0.35%
Microsoft Visio	Render Visio file in PNG/XAML	r	0.90%
Office Web Applications: PowerPoint	Render Microsoft PowerPoint, scroll to 6 slides	r	0.05%
Office Web Applications: Word	Render and scroll Microsoft Word doc in PNG/Silverlight	r	0.24%
Microsoft SharePoint Foundation	List: Check out and then check in an item	w	0.83%
	List: Get list	r	0.83%
	List: Outlook sync	r	1.66%
	List: Get list item changes	r	2.49%
	List: Update list items and adding new items	w	4.34%
	Get view and view collection	r	0.22%
	Get webs	r	1.21%
	Browse to all site content page	r	0.03%
	View RSS feeds of lists or wikis	r	2.03%
Excel Services	Render small/large Excel files	r	1.56%
Workspaces	WXP: internal protocol	r	23.00%
	Full file upload using WXP	w	0.57%

Once we get the transaction mix, we can understand which operations are most commonly used in that specific SharePoint setup. We can extract this transaction data from ULS and IIS logs. One of the easiest ways to acquire this data is to use Log Parser. It is a powerful tool available for free at download from Microsoft.

9. Gathering SharePoint Farm information

We also need to gather the following information for the SharePoint Farm in question.

• Content Size: DB size (in GB)
• Number of Content DBs
• Number of site collections
• Number of web apps
• Number of sites
• Search index size (# of items)
• Number of docs: Widely distributed content like multiple smaller files across many sites and a site collection is easier to serve then a single large Document Library with very large files.
• Number of lists
• Average size of sites
• Largest site size: This is an important tracker since it is usually an organizational need that prevents splitting that unit of content
• Number of user profiles

10. Service applications data characteristics

In addition to information on a content store, we need the following information:

• Total size of the Search index.
• The profile database total size based on the number of users in the profile store.
• The social database total size based on the expected number of tags, colleagues and activities.
• The metadata store size.
• The size of the usage database.

Armed with all this information, we can now start our analysis on which area of SharePoint is causing bottlenecks in the system.