Load and performance testing tool for SharePoint applications

MS SharePoint web applications use a special "X-RequestDigest" header containing an important value also called the "form digest". The same value appears as a parameter of some POST requests. This is a code that is inserted into each page by SharePoint and is used to validate the client requests. SharePoint uses this method as a form of security validation that helps prevent attacks with malicious data posting.

The Module for SharePoint testing ensures that both the header and the corresponding parameter in each request are passed with the correct value. It adds the following functionality to WAPT and WAPT Pro:

    • One internal function for extracting the digest code to a variable. It uses advanced search technique adjusted for all possible notations.
    • Automatic parameterization of the digest header value with the right version of the extracted code.
    • Automatic parameterization of the digest parameter value.
    • The recorded profile does not require additional header parameterization work to execute SharePoint sessions correctly.

Download

  Please note that the Module for SharePoint testing is not a stand-alone software. It requires WAPT workplace component installed.  

SharePoint Testing Tutorial

As with most web applications, the load testing of a SharePoint server farm usually consists of several important steps described below.

Set the testing goals

The very first task in a load testing project is to formulate the exact performance requirements. The purpose of remaining activities is to check that the system satisfies all those requirements. Depending on your testing goal you may need to measure and validate different performance parameters. For example, if you need to know the throughput capacity of your farm, you need to pay primary attention to the RPS and page latency. If you want to check the search performance, then you should monitor the response time for the pages initiating the search queries.

Always pay attention to the custom developed components, because they usually add most significant performance problems to the system operation. If you have a previous version of your system working in production, or a very similar system, you can use server logs and usage statistics to estimate the required load parameters. At the same time you should consider business requirements as the most important source of performance targets. Always use conservative approach by checking that your application meets the requirements even when the test load decently exceeds the load estimated for the normal system use.

Prepare the testing environment

It is not desirable and in some cases even impossible to test the production version of your system. Therefore you need to create a copy of it, which should be configured as close as possible to the production copy. This means that you should clone not only the SharePoint server farm, but SQL server and all supporting services. If you have a load balancer, you should also include it in the list. It is preferable to fill the system with the sample production data, so that its initial content would be close to what you expect for the real world scenario.

Design your test

First of all you need to choose what typical user sessions you will use in the test. Do not try to cover all possible paths in your application. You only need to apply ones that create different load on different system components. For each type of users you should create a separate profile, however do not create more profiles than necessary. Use variables with session-specific values to make each session different.

Pay attention to the validation of the page content. This is important, because sometimes errors are not reported by HTTP codes. You need to insert automatic checks to confirm that significant steps (like posting data) result in correct server responses. Setup the performance counters to monitor the work of different system components during the test.

Choose load generation components

You need to select proper hardware and software components for the test load generation. First of all, you should check the capacity of a single load agent or engine for your specific test. Increase the load while all system resources, including CPU, memory and network usage percent remain below critical values. Once the maximum load per unit is determined, you can plan the number of generating units you need for the full test.

Run the test

Start testing with a small number of virtual users. This will let you check that your test is designed correctly and there are no obvious problems in the system. Increase the test volume gradually in subsequent tests. Do not forget to make system cleanup to return the test data to the original state.

At the end of the testing run an endurance test for a long time (8-24 hours) with periodic load and a stress test with a very high number of virtual users. This lets you check how the system responds to an overload.

Interpret the results

Unless you specify exact criteria that may be checked automatically for your performance statistics obtained during the test run, you cannot quickly check if the test was successful or not. On the other hand, such automatic checks developed for a specific application may require some experience that comes from the analysis of the previous results. Once you have identified all "weak points", you may create valid criteria, but for the initial test run you need to apply some general practices provided in the following checklist.

SharePoint Testing Checklist

After you complete the testing, you usually get tons of charts and numbers in the report. While you may need to perform a sophisticated analysis to troubleshoot a specific problem, there are few things that you need to check for any test right after running it.

Correctness of the results. All user sessions executed in the test should be emulated correctly. If you see multiple sessions failing at the same request and the percent of such fails does not depend on the created load, you should research this further in the logs. Another common problem that may invalidate results is the performance of your testing environment. You should check that the CPU and network usage levels on the load generating systems have always been below 100% during the test.

Errors. The error rate should be at an acceptable level, which is usually below 1%, if we consider session fails. Note that for pages and hits the error rate may be significantly smaller, because each failed session usually contains only one page error and may also include successful pages. You should also analyze error rate for specific pages. For example, if the error rate for search requests is higher than for other transactions, you may need to further analyze the database performance.

Response times. Typically response time grows with the growing load. While this is a normal server behavior, you should check that the average time for each test period remains below the target value. Do not consider too short periods with only few responses, as this data may be occasional and misleading. Check average response time for each page request and pay less attention to the average time for the whole profile, because it includes static calls, which may be processed very fast.

Throughput numbers. The total number of processed requests and completed sessions per second is an important parameter showing general system capacity. In case of normal system operation it should change almost in line with the growing test load. If you see that at some point it becomes constant in spite of the growing number of virtual users, this may signal that the system has reached its performance limit. The amount of uploaded and downloaded data is important to check the network and web server capacity.

Performance counters. You can finally take a look at the values of performance counters for specific servers, if you set up such monitoring. This will let you identify bottleneck components of your system.