Testing procedure and results used to establish capacity guidelines

Overview

This document describes the testing methodology and results that were used in determining capacity recommendations for those planning to add Aurea Social to their existing SharePoint environment.

The resulting capacity guidelines appear both here and in the Aurea Social Planning and Installation Guide.

Because Aurea Social runs as an application within the SharePoint 2010 or 2013 platforms, its performance characteristics have a direct relationship to the performance characteristics of SharePoint.

Therefore, Aurea Social capacity planning guidelineswere developed to express the amount of extra work the platform needs to do when running Aurea Social, above and beyond the work required to run a baseline SharePoint configuration, as a fraction of that baseline amount of work.

Although this testing was performed against version 1.2 of Social Sites (now known as Aurea Social), this guidance has proven to work well in subsequent versions.

The testing methodology used to develop these guidelines somewhat follows the performance testing methodology contained in a performance case study, Case Study for Capacity Planning for My Sites installation, performed at Microsoft.

That case study compares a set of performance tests run in various SharePoint configurations ranging from a single machine hosting the web front end, application server, with a separate machine hosting the SharePoint databases; to a farm environment configuration with multiple web front ends, application and database servers.

As performance testing for the Aurea Social product has different goals, the methodology mentioned in the case study are not followed exactly. These tests were performed to show how SharePoint with Aurea Social scales in relation to a base SharePoint installation.

Assumptions

  • Authentication performed via NTLM

Glossary

  • WFE: Web Front End server
  • AS: Application server
  • DB: Database server
  • AxBxC (Graph notation): This is the number of WFEs, ASs, and DB servers. For example 2x1x1 stands for 2 WFEs, 1 AS, and 1 DB server.
  • RPS : Request per second. The number of request received by the server in one second.
  • CPU Load: processor utilization
  • TRT: Total Response Time. The sum of the time taken for all request related to a page to respond. This includes the response time for the initial page, and all AJAX requests made by the page for the additional data. The AJAX requests are included because the Activity Stream web part obtains it's working data mainly through AJAX requests. This does NOT reflect the time taken by the browser to render the response data.
  • Green Zone:
  • CPU Load <= 50% (selected because it seems to be widely recognized value at which servers should stay under during normal operation. If a system runs at more than 50% it is less likely to handle spikes in traffic without affecting the perceived performance of the system)
  • TRT < 3 sec (select for customer feedback)
  • VSTS Load: Threads used by Visual Studio Team System (VSTS) to simulate virtual users.
  • SP Page: The Share Point Page used during testing. A default page create from a standard Share Point page template that contains no Skyvera Social content, in this case the default site welcome page
  • AS Page: A blank Share Point page containing a Skyvera Social Activity Feed web part.