Sharepoint Stress Test

In search for the way to stress test my Sharepoint, I stumbled upon Microsoft Application Center Test (Microsoft ACT). ACT is a part of Visual Studio .NET 2003 so it isn't available as a standalone application. I wouldn't call ACT the ultimate stress test for SharePoint, but this is valuable tool to mention. The point of stress testing SharePoint is to see or at least get some kind of feeling how much users can your SharePoint handle. This is valuable information you need to know if you are building web pages, portals or intranets. The important thing is - don't forget to stress test your web site BEFORE publishing it (making it available for your audience) - or you could end up in dead-end, having your web site experience to be bad and sluggish.

As a starting point, I would suggest that you find some of your past projects (web sites), use any of existing intranet websites - something that you know that is working correctly and that it's performance was not an issue before. Then I would sugesst you stress test that website and see what numbers you will get as a result of stress test.



Example above shows very low RPS (Requests Per Second) number. This is because the network link was a bottleneck in this test scenario. Of course, when stress testing system - you need to setup test environment where there are no bottlenecks between you (testing system) and SharePoint frontend (tested system) - otherwise you will see irrelevant numbers in ACT.

Testing system
Testing system is the machine where you install ACT (Visual Studio) and use it as client, to connect to the website you wish to stress test. I suggest you place your testing system on the same network switch where your SharePoint platform is. Use gigabit network cards if available(100Mbps is minimum). Install ACT on any P4 or multi-core CPU system with at least 2GB of RAM memory where at least 512MB is available/free to operate ACT. I was using my DuoCore laptop as a testing system.

Tested system
Tested system is the machine (solution, platform or system) where you host your website. If you are testing more complex (multi tier, multi-machine) platform like SharePoint, where you have few servers, two or more in loadbalanced frontend and DB server in backend - then you test frontend web servers. I don't want to talk about the system design (that is whole new topic) but you have to keep in mind that bad system design will have drastic influence on this test results. For example, slow disk performance on DB server could result in sluggish website performance on web frontend and overall result would be poor performance of the whole website (showing low RPS numbers). This is why it is important to have good basis for each part of the solution.
Anyway, I assume that servers are ok, network links between servers (if any) are ok, there are resources (RAM, CPU) available. As previously said - tested system is accessed through frontend web servers and this is what we need to test.

Goal
By testing performance of frontend web server we are testing the whole solution. The goal of stress test is to stress frontend web servers with enough load until we reach point where frontend(s) CPU usage is constantly reaching maximum numbers or even better - when we reach CPU usage of 90%. 90% of CPU usage should be our goal here because after 90% of CPU usage - system is being less responsive and it is tending to loosing packets and we do not want to have that. When we reach 90% of CPU usage on frontend, we should stop adding load on the website and write down our RPS numbers from ACT. When we find out our RPS numbers - we can compare these to other systems or if we find these numbers to be lower then we expect them to be - we could upgrade existing server or add another web server in load-balanced frontend and run the stress test again. The point in adding additional web servers into load-balanced frontend is to reach the point where we are unable to reach 90% of usage on web server becuase another component of the system is performance bottleneck (e.g. disk or CPU on DB server)