# Performance Test SharePoint

- Link: https://sharepointtechnicalsupport.com/2015/04/29/performance-test-sharepoint/
- Published: 2015-04-29T08:25:20+05:30
- Author: Deviprasad Panda

**Why Performance Testing ?**

If you work on a team responsible for the delivery of SharePoint into your organization
there’s usually a mountain of tasks to complete before making it live. One of the
most vital tasks is to make sure that SharePoint is “fast” enough to meet the requirements
of your users. If you get performance problems after going live this can easily 
ruin all of your hard work and – even worse – your users will think SharePoint sucks!

So, by the time you “go live” you should be confident of the following :

 * You know the maximum load your service can take.
 * You know your service can run for a pro-longed period of time.
 * You know the point at which you may need to add more servers, so you can plan.
 * When you do get to maximum load you need to know where the bottle necks in your
   service are, (e.g. SQL, Network, SP servers).

If you don’t know these metrics up front, then you are going to have to react as
problems occur. If you have to react it will be probably be done under extreme pressure,
usually because your boss is yelling at you!

**So how do you find out these performance metrics ?**

One of the best ways to discover how well your environment can cope is to carry 
out some performance tests using a tool that will emulate the load and expected 
journeys of your user base.

**User Journeys**

Not every user will use SharePoint in the same way. You will have some users that
download a document, some that will publish documents, some that will use Search,
or even some that will use be 100% socialites. In the testing world these usage 
patterns can be mapped onto something called a User Journey. To get started with
Performance Testing, you will need to know what these journeys are likely to be 
and also what the mix will be. You can either take an educated guess (“guestimate”)
on what these journeys will be or even better, run a pilot on a good cross-section
of staff before going live. You can then use the actual usage data from the pilot
phase and feed that into a typical user journey. Both SharePoint analytics and the
IIS logs will give you all the data you need.

Once you have this data you can then list all of the types of journeys,

e.g. :

**“Casual Browser”**

 * Log-in
 * Hit the home page
 * Do a search
 * Read a document

Another journey may be :

**“The Social User”**

 * Log-in
 * Hit the home page
 * Go to their MySite (some pre-provisioned, some not)
 * Add a status update
 * Add a forum post
 * Like a document

**Visual Studio Performance Testing**

If you have Visual Studio Ultimate, you can take advantage of the testing tools 
that ship with it. There are a few others such as Load Runner, but they can be pricey.
If you take time to learn Visual Studio test tools you will soon be able to perform
adequate tests. The other great side effect is that you also are functionally testing
your application. So once you automate your testing, you can use it to repeatedly
test your app.

Once really cool thing about Visual Studio Testing is that it’s really easy to record
a user journey by simply using the browser to use SharePoint. Once you have completed
the journey it will be saved as a web test so that it can automatically be reused
under load in your Performance Tests.

To read more about Visual Studio Testing tools go [here](http://msdn.microsoft.com/en-us/library/vstudio/dd293540.aspx).

**Visual Studio Test Agents**

For large implementations, it’s impossible to emulate anything more than 50 users
from 1 machine (aka Test Agent). You will be constrained by the machines CPU, Memory
or Network I/O. To increase the load you need to install the Visual Studio Test 
Agent service on more than 1 machine. As an example, to emulate 600 concurrent users
I used 10 machines to spread the load.(It’s quite easy to see when a machine is 
constrained as VS collects performance data from the agent and things go RED.)

Once configured, each Test Agent, will emulate several users using SharePoint. Once
the Agent has the performance data they will log it to a common SQL Server where
it can be analysed.

Note! You don’t need to buy specific machines for this, you should consider using
your existing developer machines. It’s VERY likely you will be doing this kind of
testing out of hours, so it’s silly not to use them.

**What performance data to you need to gather ?**

To understand what to look for does require a good understanding of machine architecture
and performance counters. However, Visual Studio really helps as it has a pre-recorded
set of “important” counters. Each counter has a pre-defined threshold, so it will
be obvious if there is a problem. For example, if your SQL Server CPU hits 95% this
be will clear to see.

The main things to you want to record for each type of test are :

 * Test Duration
 * WFE’s in Load
 * Agents used
 * Avg. User Load
 * Pages / Sec
 * Avg. Page Time (Sec)
 * Requests / Sec
 * Requests Cached %
 * Avg. Response Time

_Please note, you should gather performance data from all servers involved in providing
your SharePoint service. This includes application servers, WFE’s, SQL Servers and
also non SharePoint servers. There could be a bottleneck in any one of these that
can cause knock on effects and resulting slow performance. _

**Always test customised code.**

Microsoft have already tested standard SharePoint functionality. If there were performance
issues they would already be well known and probably fixed. However, Microsoft cannot
test any customizations (i.e. code) you have done. Make sure anywhere you have new
code (e.g web parts, event receivers, custom pages ect), you include it under load.**
Custom code is the most likely cause of performance issues as it’s unlikely your
developers will have tested it at the loads it will be used at.**

Having said that, you still want to test standard SharePoint as you may have under
powered kit. I am just saying pay special attention to custom code.

**Vary the users, browsers and network mix.**

Visual Studio allows you to log-in as different types of users. Do this. Different
types of users can cause different paths of code to fire. You may have personalisation
features, or different security models that come into play based on user.

You can also emulate different browsers and networks. Try and match your organization
closely.

**What type of tests do you need to perform ?**

The type of tests you can carry out will generally fall into one of these types :

_**Goal based Test**_

The intention of the Goal-based test is to identify the number of page / requests
that can be served while the WFE’s are running at around 70% utilisation. The test
runs for 10 minutes and readjusts load based on CPU utilisation.

_**Soak Test**_

The intention of this test is to hit the production farm at about 50 – 75% of expected
peak Usage over long periods of time. This will hopefully identify specific problems
that are time related, such as memory leaks, or scheduled tasks that disrupt service.

_**Stepped Tests**_

The purpose of this test is to gradually ramp up the User load to find the point
at which response rates start to fall away.

_**Constant Load Tests**_

This type of testing hits the servers with a constant load that is expected at peak
performance.

**What are the performance steps ?**

In summary, here’s the high-level steps that you need to go through :

 1. Identify your user journeys.
 2. Records your user Journeys using Record and Play with a browser and Visual Studio.
 3. Create Test Scenarios in Visual Studio – (Vary the users, time, browsers, networks,
    journeys).
 4. Configure “Test Agents” to increase the amount of load.
 5. Run the Tests.
 6. Analyse the results.
 7. Publish findings and make recommendations.

**The Sample Report **

This sample performance testing report is a 25 page report taken from an actual 
SharePoint 2010 farm serving 15,000 users. The Farm has 2 App Servers and 4 WFE’s.
If you need to do Performance Testing in your organization, you may wish to use 
it as a reference point.

### Share this:

 * [  X ](https://sharepointtechnicalsupport.com/2015/04/29/performance-test-sharepoint/?share=twitter)
 * [  Facebook ](https://sharepointtechnicalsupport.com/2015/04/29/performance-test-sharepoint/?share=facebook)
 * [  WhatsApp ](https://sharepointtechnicalsupport.com/2015/04/29/performance-test-sharepoint/?share=jetpack-whatsapp)
 * [  Email ](https://sharepointtechnicalsupport.com/2015/04/29/performance-test-sharepoint/?subject=%5BShared%20Post%5D%20Performance%20Test%20SharePoint&body=https%3A%2F%2Fsharepointtechnicalsupport.com%2F2015%2F04%2F29%2Fperformance-test-sharepoint%2F&share=email)
 * [  Telegram ](https://sharepointtechnicalsupport.com/2015/04/29/performance-test-sharepoint/?share=telegram)
 * [  LinkedIn ](https://sharepointtechnicalsupport.com/2015/04/29/performance-test-sharepoint/?share=linkedin)
 * [  Tumblr ](https://sharepointtechnicalsupport.com/2015/04/29/performance-test-sharepoint/?share=tumblr)
 * [  Pinterest ](https://sharepointtechnicalsupport.com/2015/04/29/performance-test-sharepoint/?share=pinterest)

### Like this:

Like Loading…

### _Related_