McAfee Secure

Use Performance Monitor to analyze a SharePoint farm

Exam: Microsoft 70-667 - TS: Microsoft SharePoint 2010, Configuring

It is an important part of a systems architect's job to monitor the system on regular basis. Irrespective of the purpose for which monitoring of a SharePoint is done the objective remains the same - efficient working of the system and reduction of the response time. The process of monitoring begins much before SharePoint is deployed. Stress tests can be simulated in order to identify problems arising in a system. Monitoring is a continuous process that is undertaken throughout deployment and everyday functioning of the system.

A major concept that determines performance analysis is 'bottleneck'. The term 'bottleneck' is used to describe a component in case of which the supply is less than the demand. It is that point in the system where reconfiguration, addition of resources needs to be done in order to improve performance of the system. It is important to identify the bottlenecks in order to prevent waste of resources on upgrades. Performance testing can be discussed at two stages - Pre Deployment and Post Deployment.

Pre-Deployment Performance Testing

Designing is one of the important pre-deployment stage. Published recommendations and scalability results can be used for determining server requirements. The first thing to do is capacity planning. Starting with estimated number of users, media files, documents, search and other parameters one moves towards larger factors like servers, memory size, processors etc. Capacity planning helps create an architecture that is most likely expected to meet the requirements of performance. It is important to remember that the recommendations are suggested based on typical farms and your farm may have some unique features which could be a methodology or load on the system.

For running realistic tests before deployment of SharePoint, tests have to be created. For creating a realistic test environment the following components are required:

  • A Test SharePoint Farm: This should be close to the production farm that is proposed with reference to server numbers and hardware. It is best to use the same equipment in the test environment that has to be actually used. Virtualization is only recommended in case the same has to be used in production. Organizations that have bigger budgets and strict Service Level agreements adopt identical environments for testing and actual production. A test farm can help ensure the security and scalability of a test farm.
  • Custom Components: Custom components can be developed in-house or sourced from suppliers. They have the potential of altering the performance of a farm. It is important to include these in the test environments for realistic results.
  • Realistic Sample Content: For accurate and trustworthy test results the content to be used for testing should be as close as possible to the content in the production farm. Migration techniques can be used for importing content into the test farm.
  • Load Simulation Tools: A test environment lacks the actual users. This requires that load needs to be simulated. A variety of tools can be used for the same.

Once the above mentioned infrastructure is put together, tests can be run to find out if the proposed architecture will be able to support the planned load.

Post-Deployment Performance Testing

Ideally monitoring should not cease during the deployment process or even after it. Trends need to be observed in usage and demand for detecting bottlenecks before they start having an impact on performance.

Shifting of users to the new system takes place in a phased manner. The phased movement could be department wise or by adding one project at a time. In any case, it is important to monitor performance at every stage. While reducing the risk of failure, it stimulates the system architect's confidence in the system. Even once the system is in full use monitoring cannot be dispensed with. Over a long period of time, patterns of use and demand do not stay the same creating the need of continuous monitoring.

Monitoring of performance at an early stage after deployment helps profile demands that are placed on the system and how it responds to those demands. Initial profiling of these demands is known as benchmarking and is used for comparing profiles obtained at later stages. This comparison helps in diagnosing the demand and planning the response much before a bottleneck occurs.