You know the drill. One of your end-users calls up to complain about certain pages of his site working slowly. You crack open your own browser to get an idea of the issue and the pages load instantaneously. Now you can either wait for the next phone call and hope to be able to reproduce the issue then or you can start investigating. But when you start investigating, the problem becomes that your SharePoint farm consists of many components interacting with each another. For example, there are many potential causes for a slow loading page:

a. Authentication issues
b. Errors within a web part or custom code
c. Network congestion
d. SQL or SharePoint server running out of memory or CPU cycles
e. Disk performance issues on the SQL Server
f. Indexing jobs and other timer jobs

Wouldn't it be nice to have a monitoring tool that keeps track of all the dozens of individual farm parameters and delivers a historic analysis of potential errors and performance issues? The idea here is to be able to look at all these parameters from a specific point in time to identify the issue that was reported by the end user. The below image shows that the CPU Queue length is fine most of the time, but that there are occasional peaks that slow down the SharePoint site.

Figure 1 - Processor Queue Length
 

Now we can look and see what events on the server went on at the time of these peaks to determine the reason for the performance hit. This could be indexing jobs, data requests via web service, backup jobs, console applications, etc.

When we look further, we can also see more issues related to a) IIS, b) Network, c) Paging File, d) RAM and e) the SQL Server database. Figure 2 shows us that only the memory issue is critical, but the other issues should be addressed as well at a lower priority.
 

Figure 2 - Server Metrics

Now let’s take a look at the memory issue indicated in Figure 2. Figure 3 shows that currently 83.44% of memory is used on the server, and the chart at the bottom of the screen shows that this has been the case for at least the previous 24 hours. We could now go select a seven-day history from the dropdown above the chart below and confirm that memory has been a constant issue. Figure 3 also shows that this lack of memory led to a critical number of “per process page faults per second.” Adding more memory to this server will most likely eliminate the problem.

Figure 3 - Memory Usage

How Did We Do It?
But wait, how were we able to generate the charts and metrics above to diagnose the problem? As you may know, SharePoint’s ability to diagnose this type of error is very weak. This is why our team has looked around the marketplace and found Idera’s SharePoint Diagnostic Manager. Simply install Diagnostic Manager on a machine on your network and receive real-time and historic metrics for all your SharePoint farms.

That said, next time that phone rings with an angry end-user on the line, just crack open Diagnostic Manager and look for warnings. In most cases, once you have found the issue, the resolution is very simple, especially as Diagnostic Manager explains the problem in plain English and recommends concrete resolution steps. Finding and reproducing the issue is what causes us SharePoint administrators to sweat over our keyboards.

Diagnostic Manager is a SharePoint administrator’s dream, as you can quickly diagnose problems within all of the following areas from one central dashboard:

a) CPU
b) Disk
c) IIS
d) Memory
e) Network
f) Paging File
g) Excel Services
h) Search
i) Indexing
j) SQL Server
k) SharePoint Webservice

Even better than waiting for that end-user call is setting up alerts before the situation becomes too critical. That way you can get the issues resolved without anyone even noticing. Long story short, finally there is a tool that helps us stay entirely on top of our SharePoint farms, without having to constantly monitor dozens of parameters in almost as many places.