Notes from SPC14: Load Testing SharePoint 2013 Using Visual Studio 2013… with no code!

Tuesday March 4, 2014 9:00-10:15am
Speakers: Todd Klindt, Shane Young
ITPro Session

Agenda

• No code!
• Talk about the tools
• Make some tests
• Demo Demo Demo 

Challenges

• How do you do it?
• Time and effort setting up machines
• Cost for hardware
• Fear of Visual Studio 

• You always find more you can load test as you get into it, but "doing something is better than doing nothing!" 

What you need

• Visual Studio Ultimate Edition (can use VS Test Edition) - can get this with an MSDN subscription
• Windows 7 or 8
• Windows Server 2012/2012R2
• Can also run the client parts on Windows Server itself; but its easier when running client on Windows 7 or 8 due to browser security settings on the server
• A test environment
• Nerves of steel!
• Don't test against a production environment - you can easily take it down if you don't know what all the controls do 

Terms

• Performance testing - Does it work?
• Load testing - Does it really work? Scale up the users/requests/transactions; Concurrency, etc.
• Stress testing - When does it stop working? Where do things break?
• Capacity or scale testing - Will it work for us? You have a number in mind. 

• Many orgs work at a baseline of 10% concurrency
• Heavy social, BI or search activities are sometimes causing 40% concurrency
• Currency goes up also when you have a SharePoint intranet as the default browser page for employees - every time launch browser then site page is loaded 

• Solution - one or more projects
• Project - one or more tests
• Web test - a series of web requests, can be one or more pages or actions; make each test as discreet as possible
• Load test - execution of one or more web tests; Has settings like browser, networks, users 

Demo, Demo, Demo

• Logged into Visual Studio as an account that is privileged on SharePoint box (probably not as install account)
• Run everything locally on laptop
• Start new project - under Visual C# > Office/SharePoint > Test select Web Performance and Load Test
• New project already creates a default web test - can add more (right click project, click Add, click Web Performance Test)
• Next, easiest way is to use the record button and do whatever you are going to do
• Launch the browser and do the actions you want to load test
• Go to your SharePoint page
• Do whatever
• Click Stop in recording plug-in 

• There is a plug in to the browser that allows you to control the recorder - this must load; this is why its easier to run tests on Windows 7 or 8 

• Web test gets created in Visual Studio project - a window will come up "detecting dynamic parameters" looking for form pages, submit buttons, values used during test, etc.
• Will likely not pick up "host name site collections" - ex. hr.contoso.com, it.contoso.com all in 1 web app
• The button beside the record button in VS can be used to run the web test again
• Will ask me for credentials if necessary
• Can run the web test as multiple users - helps with testing different levels of permissions
• Might want to run as users that don't have super access to SharePoint
• Want to test with users that don't have permissions (test for 401 error pages)
• Authentication errors when running web performance tests will show up in the test results
• In VS you can actually change some of the parameters that were saved during the recording 

• Ex. Add a new web test to test performance of searching on specific content 

• You can look at the code created during the recording
• You can actually add code to your web performance tests
• Great comment in the code of the web performance test:  This code was generated by a tool.  LOL! 

• There is a 'Create New Load Test Wizard' that can guide you through the process
• Provide name
• Select Think Time Profile (use recorded think times, use normal distribution centered on recorded think times, do not use think times)
• Tend to use normal distribution
• Use 'do not use think times' when you want to determine who soon will my site break
• Select a load pattern for simulated load
• Select constant load or step load (for testing when does it break), then select user count parameters
• Select 'how should the test mix be modeled'
• Total number of tests, number of virtual users, user pace, sequential test order
• Add the web tests to execute, from the available web tests you already created
• Once selected multiple web tests you can then adjust the distribution between the tests (perhaps test access to the portal more often than testing search)
• Select network types (ex. LAN speed) - select from list of network types: 3G, cable, intercontinental pipe with latency, etc…
• Relevant for internal apps if you have people coming into internal LAN server when working from home
• For this to work, you have to install a network shim on the box
• If you change this when you're RDP'ed to the box, it will kill your connection to the box
• This works only if launch Visual Studio as an administrator
• Select browser type
• Interesting to compare performance when accessing SharePoint from different browsers
• This only changes the HTTP header sent to SharePoint to contain the right browser string
• Select the % of each browser
• Select computers and counter sets to monitor
• Ex. Select the SharePoint WFE, SQL server, IIS, ASP.NET, etc…
• Will not work until machines are all in the same domain
• Select run settings - how long will the test run
• You can set the warm up period, so that the app pools can get warmed up while IIS is compiling code
• Try to hit one of each server, page you are testing because they all need to warm up separately
• Careful with the sampling rate - set it to 10 sec; don't want your box to get too busy 

Example of Performance Test Results

 

• From test results you can see where the bottlenecks are: do you need more ram, more cores, etc.
• Interesting test can be: do an IIS Reset in the middle of running a Load Test to see what the impact of doing that is when users are in SharePoint 

• You can export the test results to a CSV file or to SQL (in VS you can generate the database to store the results)
• Important concept: you need to first get a baseline - what is the farm performing like with just out of the box and recommended configuration
• Then run performance tests again once added a new component or configuration change 

• Can you simulate running tests against multiple WFEs?
• Doesn't sound like you can simulate this, but you can run the tests against a pre-configured farm with multiple WFEs 

• Another great feature: you can take an output from Fiddler and import it as a Load Test 

• Don't forget about the network pieces in front of your Windows servers or in front of SQL - these can cause performance bottlenecks that take down your SharePoint servers

     …can mistakenly make it look like your SharePoint servers are the source of the performance issues!