Follow me on Twitter @AntonioMaio2

Tuesday, March 4, 2014

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

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

  • 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 

  • 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., 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!

No comments:

Post a Comment