How do you know if your hardware has adequate resources allocated or if the service is functioning properly?
The answer lies in the old maxim: you can’t manage what you don’t measure. It applies to governing a SharePoint service, too.
I find a common gap in an effective SharePoint governance strategy is a lack of targets and measurements. One of the most dramatic differences you can make in your own SharePoint operational maturity is to establish performance targets and then measure the actual results against the targets.
When you measure actual performance against targets, it will alert you to any degradation in performance or resource over utilization. This can lead you to areas to investigate further, such as whether an application contains a bug that affects service levels. It can also provide evidence when it is time to scale up a server, such as when you notice the server consistently exhausts all its RAM or CPU resources.
I have a list of performance counters that I like to monitor along with the counter’s threshold that I’ve been using and recommending for several years now. Whenever a counter consistently measures over its threshold for a prolonged period, it generally indicates over-consumed server resources and I use the threshold to flag potential requirements to scale the farm or to investigate potential issues.
Use these counters to capture periodic snapshots of server utilization during peak and non-peak times. Available tools to monitor these counters include Windows Performance Monitor, System Center, and other operations tools.
|
Object\Counter |
Threshold/Description |
|
Processor\% Processor Time\_Total |
< 75% |
|
System\Processor Queue Length\(N/A) |
< # of CPUs x 2 |
|
Memory\Available Mbytes\(N/A) |
< 80% |
|
Memory\Pages/sec\(N/A) |
< 100 |
|
PhysicalDisk\% Disk Time\DataDrive |
< # of Disks x 2 |
|
ASP.NET Applications\Request/sec\_Total |
Trends with sharp declines can indicate problems exist |
|
ASP.NET\Worker Processes Restarts |
Any number above zero can indicate problems exist |
|
.NET CLR Memory\% Time in GC |
< 25% |
|
Logical Disk\Avg. Disk Sec/Red |
< 20 ms |
|
Logical Disk\Avg. Disk Sec/Write |
< 20 ms |
|
Logical Disk\Average Disk sec/Read |
1-4 ms for logs (ideally 1 ms on a cached array) 4-20 ms (ideally below 10 ms) |
|
Logical Disk\Average Disk sec/Write |
1-4 ms for logs (ideally 1 ms on a cached array) 4-20 ms (ideally below 10 ms) |
|
Logical Disk\Current Disk Queue Length |
< 20 |
|
Logical Disk\Average Disk Reads/sec & Logical Disk\Average Disk Write/sec |
< 85% of disk capacity |
There are other thresholds to set and metrics to monitor for a comprehensive SharePoint governance strategy, including response and resolution times for service requests, disaster recovery targets, and overall service availability. I talk about these along with a deeper discussion on performance thresholds in my first book, Practical SharePoint 2013 Governance.
The key is to be intentional about what kind of SharePoint service you want to offer and what level of service you want to provide. Once you answer that, you can identify your targets. From there, you will be well on your way to governing an effective SharePoint environment.
