Performance testing and load testing!
Yes, we know this is very important in case of web applications because we can only expect the traffic while going live for end users. We actually don’t know real picture of load on the web application. Based on our experience and expected target users, we plan the architecture of system which is called as Capacity planning.
When we talk about SharePoint on-premise environment, we know prerequisites and also perform load testing before going live for end users. But what happens, in case of SharePoint Online?
In this article, we describe how can we deploy to SharePoint Online without performing traditional load testing since it is not permitted. Load testing in SharePoint Online is strongly discouraged but we have few ways to make sure that site will not produce a poor experience when you launch the site.
With SharePoint Online, we don’t have to do capacity planning as it is done as a part of service offering by Microsoft. With on-premises environments, load testing is used to validate scale assumption and finding breaking points of the farm by saturating it with load. With SharePoint Online, Microsoft does it differently. As this is a multi-tenant environment, Microsoft has to protect all tenants in the same farm. This means we’ll get disappointment and misleading results if we attempt to load test our SharePoint Online environment.
The main benefit of SharePoint Online over on-premises deployment is it’s elasticity of the cloud. Microsoft’s large scale environment is set up to service millions of users on a daily basis so it is important that they handle capacity effectively by automatically expanding farms, as and when needed. This article explains how Microsoft plans for capacity growth and scale out in place. The article also covers approaches for us to use that don’t involve load testing.
How Office 365 predicts load and expands capacity
SharePoint Online server capacity management work is done through two methods:
1. Capacity forecasting
2. Load-balancing on single server farms
Unlike planning for an on-premises environment, for capacity forecasting in SharePoint Online, we are able to compile statistics and graph potential requirements in any given server group. The aggregate demand might look something like the Requests in zone (where a zone is a group of SharePoint farms) growth line in the image below:
While the growth is unpredictable in any one farm, the aggregated sum of requests in a zone is predictable. By identifying the growth trends in SharePoint Online, we can plan for future expansion.
In order to efficiently use capacity and deal with unexpected growth, in any farm, we have automation that tracks front-end load and scales up in place, when needed. The main metric we use as a signal to scale up front ends is CPU load. Our goal is to keep peak CPU load under 40%. This is in order to have enough buffer to absorb unexpected spikes. As load approaches 40% in steady state, we add front ends to farms.
Additional servers can be quickly added to a farm, using those which have been previously added to the zone through the usage forecast.
How should we plan for a site launch?
Microsoft suggests, we should expect that the farm on which your new site launches will automatically be monitored so that new front-end servers are added, as described above. For this reason, Microsoft doesn’t need any notification for your new site launch.
However, we should launch the application in various phases and with slowly introducing the system and making improvements as the system gets more use. This also allows Microsoft to react to the increased load as the site is rolled out to more and more users.