SharePoint is an information share and documentation management platform that is essential for the majority of businesses throughout the world today. But you already knew that, right? This article outlines SharePoint performance monitoring and its feats. The focus is on highlighting the most common performance issues and advising on best practices to help you with solving them.
Is SharePoint performance monitoring important?
If you’re a SharePoint admin – Yes, it’s absolutely crucial!
SharePoint performance monitoring is the key to providing optimal usage experience to end users on your servers. Often, finding out why page load issues occur, or whether it is your database running out of free space, can carry the full weight of running your business.
It is imperative to monitor your SharePoint environment 24/7, as opposed to only starting when you’ve already experienced issues or slowness. When problems like massive database response time and page slowness occur, every minute matters. If neglected for a short period of time, it will affect your users and bring work disruption to your company.
Also, it is smart to have the performance logs of all SharePoint farms at your disposal at all times. SharePoint performance monitoring in real-time, and historically, allows you to place performance metrics against a set of server baselines, giving you the insight into a potentially arising issue. Perhaps you’ll need to check the SQL Server logs from three days ago to find the problem cause, or need to prove that CPU usage on WFE servers is spiking only at a particular time of the day.
There are several benefits to be gained through SharePoint performance monitoring:
- Prevent your disks from running out of free space before the SharePoint stops being available for your end users. Bear in mind that even today running out of disk space is the main reason for SQL Server outage.
- Reduce your page load times by detecting and fixing problematic SharePoint services on your servers.
- Find out if your SharePoint servers have enough physical memory by checking buffer cache hit ratio or other SQL buffer-related performance counters.
- Detect and audit database latency problems caused by lack of physical resources available on your servers.
- Avoid the lack of adequate hardware resources allocation and easily spot resources’ overutilization.
- Improve response time of your WFE and APP servers by minimizing database latency issues.
What are the common SharePoint performance issues?
Like all technical platforms, SharePoint has a list of problems that you’re due to experience sooner or later working in most SharePoint environments. The focus here is on the performance issues that cause disruption to user workflow, and best practices for solving them. These are just some that tend to be a bit more common in the everyday SharePoint administration process.
Slow database response due to bad database server design or underrated capacity
Your wait status and latency numbers in performance metrics point to your I/O subsystem as the root cause of the issue. You need to change the underlying storage configuration so that it can handle more IOPS and provide the necessary MB/sec throughput for your SharePoint environmental needs.
Recycle bins consume a lot of space
Recycle bin files have two stages. The first is during the 30 days following deletion, when they are user-recoverable. The second is when they are used by site collection admins to recover long-deleted content. So, if you don’t enforce a quota, it won’t stop growing. Believe it or not, it consumes 50% of SharePoint total quota size, so be sure to stop it from getting out of control.
Badly planned SQL Server Deployment
If you have plans for the growth of your SharePoint environment, be sure to consider the upgrade of your SQL Servers accordingly. An unworthy SQL server is most likely to be a culprit in persistent system failure. What you need to look for are physical resources, optimally tuned SQL configuration, and SharePoint databases with recovery and backup set-up.
Bad connection between the WFE and SQL Server
This is a frequent bottleneck in environments with lower network capacity. You need to assure enough bandwidth between the WFE and the SQL server: at least 1Gbit to be on the safe side in preventing connection issues.
IIS out of memory conditions
Make sure that your front-end servers have enough RAM memory so that cache can be stored without swapping to the slow physical or virtual disks. Every SharePoint server needs to have an appropriate amount of memory since nowadays RAM is not expensive. It’s better to have some physical memory sitting and waiting than not having it at a critical moment, forcing the server to swap to the disks.
You can check out more detailed information about SharePoint performance issues and ways to solve them on Microsoft TechNet. Remember that SharePoint is a complex system and you need to monitor your environment constantly.
Which are the SharePoint performance metrics to look for?
If George Orwell were a SharePoint admin, he’d probably say: “All performance metrics are equally important, but some are more important than others.” Guided by that thought, the following performance metrics are brought to your attention, as they are likely to point out the most common SharePoint performance issues.
|Performance metric||Warning||Metric Description|
|SharePoint Publishing Cache: Number of cache Compactions||>2||Indicates that the SharePoint cache may lack in size.|
|SharePoint Publishing Cache: Object cache flushes/Sec||>0||Cache flushing during peak-use hours slows down performance.|
|SharePoint Publishing Cache: Object Cache Hit Ratio||<1||Small number indicates the searches for non-published items.|
|SharePoint Publishing Cache: BLOB Cache % full||> 80%||Indicates that the SharePoint cache may lack in size.|
|ASP.NET Applications: Cache API trims||>1||Indicates the lack of allocated memory for ASP.NET output cache.|
|ASP.NET: Requests Queued||>400||Indicates the need for more Web Servers since a high number of requests can cause slow page load.|
|ASP.NET: Requests Rejected||>2||Indicates the need for more Web Servers due to server busyness.|
|ASP.NET: Worker Processes Restarts||>1||Any restarted worker process can indicate a potential problem.|
|Memory: Pages/Sec||>20||Large value for page writes to memory indicates the lack of RAM memory. *Note: Tends to jump over 200 often.|
Microsoft SQL Server
|Performance metric||Warning||Metric Description|
|SQL Server General Statistics: User Connections||N/A||Number of users connected to the SQL server at the moment. Warning value is server dependent.|
|SQL Server Buffer Manager: Page life expectancy||<400||Time the page is saved in the buffer cache, a low number indicates possible low RAM memory.|
|SQL Server Buffer Manager: Lazy Writes/Sec||>15||Number of bad pages being removed from buffer per second. Zero is ideal.|
|SQL Server Buffer Manager: Buffer cache hit ratio||<90%||Percentage of data successfully fetched from a cached page. Low RAM memory indicator.|
|SQL Server SQL Statistics: Batch Requests/Sec||>1000||Indicator of CPU usage by SQL Server affected by number of queries.|
|SQL Server SQL Statistics: SQL Compilations/Sec||>100||Large number of compilations per second indicates high resource usage.|
|SQL Server Access Methods: Page Splits/Sec||>200||Large number of page splits indicates high resource usage|
|SQL Server Access Methods:
|>100||Full scans value can be ignored unless it peaks proportionally to CPU.|
|SQL Server Locks:
|>1||Indicates time passed for one server lock.|
|SQL Server Locks: Number of Deadlocks/Sec||>1||Number of deadlocks on the SQL Server per second.|
|SQL Server Cache Manager: Cache Hit Ratio • > 85% •||<85%||Indicates the ratio between cache hits and lookups for plans.|
|SQL Server Databases: Transactions/Sec||N/A||Number of transactions per second on the SQL server, warning value is server dependent.|
Learn more about SharePoint performance monitoring and metrics on Microsoft TechNet.
How to make SharePoint performance monitoring effortless?
So, it is concluded that SharePoint performance monitoring is key to effective SharePoint governance strategy. All you need now is a reliable tool to make this process much easier for you. Meet SysKit – the powerful SharePoint performance monitoring tool!
SysKit is an agentless tool that allows you to monitor your remote and production servers by using Windows performance counters API so that you don’t need to install any third party software on your mission critical SharePoint farm. All your SharePoint farms are monitored from a single console, and you can easily separate a large number of servers into logical server groups if you have e.g. UAT, DEV, or production farms.
With SysKit, you have every existing SharePoint performance metric at your fingertips, and you can fully customize your server performance monitoring. Monitor all critical SharePoint, SQL, or IIS services. On top of that, if any of the services stop, the application will restart it and inform you that something is going on and you need to check the servers. Further to that, SysKit will send you automatic alerts when something suspicious is happening on your servers. For example, if SQL servers run out of free space, or CPU usage is unusually high on one of your WFE servers. The bottom line is that you can spot the issues before the real problems arise!
Utilize one dashboard for all your SharePoint servers, wherein the application will show red alerts only for the farms that are experiencing some kind of issue, enabling you to drill down deeper into that specific problem. You can check all the servers in one farm, or add more SharePoint farms and then check the data for all of them from a single location.
SysKit is developed by the same company behind the award-winning SharePoint admin tool, SPDocKit, which enables you to generate SharePoint documentation, analyze permissions, and compare farms. You can download SysKit FREE trial here, and if you have any questions be sure to contact us.