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!

1 comment:

  1. IEEE Project Domain management in software engineering is distinct from traditional project deveopment in that software projects have a unique lifecycle process that requires multiple rounds of testing, updating, and faculty feedback. A IEEE Domain project Final Year Projects for CSE system development life cycle is essentially a phased project model that defines the organizational constraints of a large-scale systems project. The methods used in a IEEE DOmain Project systems development life cycle strategy Project Centers in India provide clearly defined phases of work to plan, design, test, deploy, and maintain information systems.

    This is enough for me. I want to write software that anyone can use, and virtually everyone who has an internet connected device with a screen can use apps written in JavaScript. JavaScript Training in Chennai JavaScript was used for little more than mouse hover animations and little calculations to make static websites feel more interactive. Let’s assume 90% of all websites using JavaScript use it in a trivial way. That still leaves 150 million substantial JavaScript Training in Chennai JavaScript applications.