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!
No comments:
Post a Comment