There are two options when it comes to where to install your ULS Viewer: locally on your client or somewhere on your server farm. You should install the ULS Viewer on your local client, not on any of your SharePoint farm servers. There is no reason to be logged on to your production environment if you do not have to be there.

This demonstration sets up the ULS Viewer in a Windows 8 Enterprise (x64) environment. ULS Viewer requires the “.NET Framework (includes .NET 2.0 and 3.0)” Windows feature to run. After granting read access to the ULS LOGS folders for your environment(s), and after installing the ULS Viewer, point the ULS Viewer at all the LOGS folders for your farm.

Start by Shift + right-clicking the ULS View icon and selecting Run As Different User (see Figure 11-1). Start the program as the user (hopefully the SharePoint Admin Account) that you gave the read-only permissions for the LOGS folders.

Figure 11-1. Run the ULS Viewer as the farm administrator.

You are then going to start adding the ULS LOGS folder locations that you want to monitor (see Figure 11-2).

Figure 11-2. Adding the ULS LOGS folders to the ULS Viewer.

Put in the location of the LOGS folder into the Log File Location text box, as shown in Figure 11-3.

Figure 11-3. Enter the location of the LOGS share folder in the Log File Location box.

You should have one tab for each log file location entered.

As shown in Figure 11-4, select the level of severity of the messages that you wish to see for each server, enable the correlation tree, verify that you have the Show Notifications option turned on, and then save your workspace.

Figure 11-4. The settings for the common features of the ULS Viewer.

You can create several versions of workspaces to make it easier to track what is important to get your task completed.

The ULS Viewer from Microsoft is a fantastic tool to start the validation process of your installation through the tracking of critical errors. While some might be tempted to leave the viewer running all the time to find critical errors, it is best to just use the tool when needed.

If you are installing Fiddler on a Windows 8 client, you should download Fiddler4 from http://tinyurl.com/PCfromDC-Fiddler4. After downloading the program, run the installer as the Administrator, click Next a couple of times, and finally close out the installer; your default browser should pop up and tell you that your installation was successful.

There are add-ons that you can install for Fiddler to help with a variety of tasks. You can review the add-ons at http://tinyurl.com/PCfromDC-Extensions. With Windows 8, you have the ability to capture the app traffic as well, so make sure that if you are using Fiddler for only capturing your SharePoint HTTP traffic, keep the tracking of Windows 8 apps functionality disabled to keep your web session traffic capture as clean as possible.

Now that you have figured out where your logs are located and have seen that you actually have log files to review, what is an efficient way to comb through the data? Microsoft has created a program called Log Parser to help you solve that problem. At the time of writing this chapter, Log Parser is at version 2.2, and was published in April 2005. You can download Log Parser 2.2 from http://tinyurl.com/PCfromDC-LP22.

Log Parser is a powerful tool that can handle several types of input file formats, including:

Running queries against log files that might have millions of records is a daunting task, and not something that you want your web server to manage along with the web traffic. So just like you did previously in the Setting up ULS Viewer section, you are going to share the IIS LogFiles folder with read-only permissions for the SharePoint administrator so that you can run Log Parser from your client desktop and not from the server.

While Log Parser is an invaluable tool, there are a couple of problems with using Log Parser. One problem is that Log Parser is a command-line executable, so there is no GUI. The second problem is that you need to be able to write SQL queries to return the data that you are interested in finding. For those of you who do not want to spend the day looking up queries on Bing and are tired of command-line operations, there is an add-on from the Exchange Gallery of Microsoft TechNet called Log Parser Studio (LPS). You can download LPS from http://tinyurl.com/PCfromDC-LPS. Once you have set up your folder share and you have installed Log Parser, you can install LPS.

With your LogFiles folder permissions set for only the SharePoint Administrator, Shift+ right-click the LPS icon and run LPS as the SP Admin. Once LPS opens up, familiarize yourself with the program layout (see Figure 11-9). Notice that there are 117 queries already created for you, along with descriptions and the actual query as well. This should be enough to help you create your own queries and add them to the library.

Figure 11-9. An introduction to the LPS layout.

To start getting back information, assign a log file or folder to have LPS query against. Press Log Folder to open up the Log File Manager window. Next, add the folder and the files that you want to query. When you go to select a folder, you will actually have to select a file to open, but once you click Open, notice that the saved file is marked like all the files within the folder (see Figure 11-10).

Figure 11-10. Addition of the log files and folders.

Out of the box, LPS does not give you the ability to query how many requests are made per second, but there is an out-of-the-box query to return the number of requests per hour. Look for the IIS:Request Per Hour query, and double-click the row to open up the query window, as shown in Figure 11-11.

Figure 11-11. How to run a query to return the requests per hour from IIS.

After you run the query, the number of requests per hour for that site will be displayed. Click the green arrow to export the .csv file so that you can work with the numbers in Microsoft Excel. To get the number of requests per second (RPS), you take your total amount of requests for the hour and divide by 3,600. Another important thing to keep in mind is that if you have a network load balancer (NLB), and your total requests per hour are dramatically different for each web server, then you have some research to do into why your NLB is not distributing calls evenly.

There are lots of questions that will need to be answered and a lot of work that will need to be done before moving on to load testing. As with any plan, you should know ahead of time what your goal for testing is going to be. You should understand the objectives and how to reach them consistently and reliably. If you create a test plan and cannot re-create the results, then you do not have a valid test plan. Your tests need to be reliable, consistent, and repeatable.

What is your objective? If your objective is to measure throughput capacity, then pay close attention to the RPS and page latency. If you are testing search performance, you might be looking at your crawl times and indexing rates. If you want to measure hardware performance, you might look at % Processor Time and RAM utilization. If you are testing pages that have custom code, conduct your performance testing of the code in isolation before bringing it into SharePoint for testing. After your isolation testing, compare the performance of how well your custom code worked in isolation compared to how your code ran within SharePoint. You really need to know and understand your objective so that you can create a valid test model before starting your performance testing, especially if you are planning on conducting load testing as well.

After you have determined the metrics that will tell you if your performance is acceptable, and you have completed a metrics table that also tells you what is marginal and what is not acceptable, it is time to start doing performance tests.

The odds are good that you are interested in creating an environment that loads a webpage quickly, uploads documents quickly, and allows you and your users to view documents quickly. To help with determining the baseline numbers, there is a tool created by Microsoft called Visual Round Trip Analyzer (VRTA). This is another tool that was built upon Netmon (previously discussed in the Microsoft Network Monitor section) and is downloadable from http://tinyurl.com/PCfromDC-MSVRTA.

The VRTA helps you visualize the download of webpages and identify best practices, and it will even recommend changes to your environment that will help improve web performance. VRTA examines the communications protocol, identifies the causes of excessive round trips, and recommends solutions.

Test your environment over a variety of scenarios. For example, you might test the following:

Figure 11-12. Using VRTA to look at the page load speed of a stale page.

Figure 11-13. Using VRTA to look at the page load speed of a freshly opened browser.

Figure 11-14. Using VRTA to look at the page load speed of a refreshed browser page.

Figure 11-15. An example of returned page speed after the browser cache has been cleared and the page had been refreshed.

The things that you should notice are not just the load times, but also the bandwidth efficiency and how many different items and item types (different colors) are being loaded. After you have your data captured, you can click the Analysis tab and have VRTA tell you how to improve your performance.

One way to clean up your environment and increase the performance of your pages is to look at your network’s bandwidth efficiency. Another way to improve your performance is to look at how you have your CSS files, JavaScript files, and image files loading. To track down your speed issues, you should consider using IE Dev Tools. You can use these tools to create a waterfall presentation of your network traffic and troubleshoot your performance issues. With IE Dev Tools, you are going to focus on page loads after your browser cache has been cleared and page loads when you refresh a page.

As shown in Figure 11-16, there are two ways to get to your IE Dev Tools: either by pressing F12 or selecting Tools (Alt + x) | Developer Tools.

Figure 11-16. Enabling IE Dev Tools.

Next, as shown in Figure 11-17, select Network | Start Capturing. Once you are capturing your network traffic, either go to one of your pages or refresh a page that you have open. When your page starts to load, the summary waterfall will start to appear.

Figure 11-17. A waterfall summary of a page request and load.

There is a ton of information on this chart. You can see that this page load has 13 items downloaded, and that Bing.com was sent 9.8 KB of data and in return received 32.6 KB of information. For each item requested, you have the ability to look at the URL and view the method used for the request (GET, POST, PUT, and so on), the size of the item received, and how long the item took to download. Understanding the protocols for the results will help you improve your performance. Table 11-1 shows three result codes as defined by W3.org.

You can read through all of the status code definitions by going to http://tinyurl.com/PCfromDC-w3.

It is important to understand the codes returned because you need to know how your requests are getting returned. If your branding team has decided to change your site’s look and feel, and you get bombarded with complaints about how slow things have become, you should know why. You do not want your branding team to say that your environment cannot handle their modifications, when the problem is actually the 30 JavaScript calls that they added.

To drill down into the network information a bit further, double-click the top URL, which should be the URL of the page that you requested. If you click the Timings tab, as shown in Figure 11-18, you should see the detailed view of the page request for the URL.

Figure 11-18. A detailed view of the page load timings.

Every request that you send has a standard set of processes that it goes through, as shown in Figure 11-19 and described in the following list. The Timings window will be a very useful tool when you are trying to fine-tune your page load performance.

It is possible to have items loaded, or deferred until after the page load, which means that the client can interact with the page while objects are still being loaded. If you want to see an excellent example of how Microsoft cleaned up their files on page load for their SharePoint.Microsoft.com site, read “How we did it: Speeding up SharePoint.Microsoft.com” at http://tinyurl.com/PCfromDC-spPerformance. This blog post was written by Tony Tai when he was the senior product manager for SharePoint Server.

Remember that performance testing is not just about your page layouts and design. You could have NLB issues, improperly set-up NIC teaming, or a bad switch that could impede page response time as well. Another way to increase performance would be to enable Kerberos authentication. This would help by reducing the amount of network traffic used for authentication and by reducing the number of times users get authenticated down to one.

When it comes to building out your test environment, the first thing to determine is the type of environment that you want to create. If you will be testing a brand-new SharePoint Server 2013 environment that has not been signed off and approved to go live, then you are probably only looking to build out a client test machine and a load agent. If you are trying to test the performance of your current live production farm, consider creating a duplicate farm to run your tests against. You will not get good baseline numbers from a live production farm if there are fluctuations in simultaneous requests to the server that you are testing, and if you do take down your farm or destroy a server, you do not want to do it to your live production environment.

There are three common types of environments used in on-premises testing web servers. One environment runs everything off one client, as illustrated in Figure 11-19.

Figure 11-19. The most basic of load test scenarios.

The other two environments separate the load agent from the client. This is done because you might have more than one load tester or because you have only one server with enough RAM and CPU processing power to handle load testing. It may also be the case that your client does not have the hardware required to run the load test scenario successfully, as shown in Figure 11-20.

Figure 11-20. Load testing using a remote load agent.

By separating the load agent from the client, it also affords you the opportunity to run multiple load agents to help load-test your environment, as shown in Figure 11-21. Eventually, after you scale out your load test, you will run into a simulated user threshold for each load agent, and you will need to add another load agent to help with your simulation. You do not want your load agent to become a bottleneck for your testing environment. Your load agent should not exceed 75 percent CPU utilization, and you should not go below 10 percent availability of your physical RAM.

Figure 11-21. Load test utilizing multiple load agents.

The first steps for creating your load test are to understand what you are trying to accomplish and how you are going to accomplish it, and know what results are acceptable or not. The goal for a load test is to find out the number of users that your environment can handle while they perform everyday normal activities, with enough headroom for service applications of SharePoint to do their job without causing errors within the farm. To help accomplish this goal, you will need to understand the following terms:

Next, you need to take a look at real numbers for how you are going to load-test your environment. If you already have an environment, pull out real numbers by using Log Parser, as discussed in the Inspecting your IIS logs section earlier in this chapter. If you do not have an established environment, there are some best-guess ratios that you can use so long as you know the number of users that will be using your SharePoint farm.

By now, you should have a farm deployed and be ready to test to see if your theory and reality for farm load are anywhere close to being equal. SharePoint is a powerful tool, and the improvements within SharePoint Server 2013 to handle requests make SharePoint a resourceful tool that can handle more than you would expect. The question is, “How much can my farm really handle?” Figure 11-22 is an example of user utilization profiles. The chart shows how you can determine a rough estimate of the minimum RPS that your environment will need to be able to handle while staying within the green zone.

Figure 11-22. A table showing the Contoso SharePoint farm utilization.

Knowing your estimated user count and peak percentage will allow you to determine how many users will be making requests, while knowing the estimated requests per hour for each user will help you determine an estimated RPS at your farm’s maximum load. It is very important to know your minimum RPS figure so that you will know if you pass or fail your load test. Odds are good that you will not hit your average RPS number during your load testing, so it will be important to be able to figure out exactly how many users your farm can actually support. As shown in Figure 11-23, your farm not only needs to be able to handle your users, but also handle the SharePoint requests as well.

Figure 11-23. A representation of how the maximum number of concurrent requests is determined.

After you run your load test, you will be shown the average RPS that actually occurred. This number will never be the same as the one from the RPS worksheet because SharePoint makes its own requests to web services, such as the farm topology service, to get information about the rest of the farm before displaying content. So your RPS will not only vary depending on what you are trying to accomplish with your load test, but also depending on your distributed cache and your request management service.

You can download the RPS worksheet from http://tinyurl.com/PCfromDC-RPSWS.

There are several tools available to conduct load tests, including web-based companies that you can use to hit your external sites. Most of these tests will work to provide your RPS and page load times but will not be able to tell you if your servers are running in the green zone or how close you are to exceeding your farm’s capacity to even respond to requests. Microsoft Visual Studio Ultimate 2012 is built with presets to inspect your servers based on the server functionality in your farm. Not enough organizations have Visual Studio Ultimate as a resource, so to show your bosses a demonstration of how amazing the product is, you can download a test version from http://tinyurl.com/PCfromDC-VS2012. Also, be sure to install any updates associated with Visual Studio 2012. If you are not notified automatically about available updates, you can download update 1 (KB2707250) from http://tinyurl.com/PCfromDC-SP1, and don’t be surprised if there is a second update available by the time you read this paragraph.

The first step after downloading Visual Studio is to install the program. For most administrators and/or architects who have never touched a bit of code in Visual Studio, installation might be a bit intimidating. Don’t worry, you will click Next a bunch of times, clear a bunch of check boxes, go get a cup of coffee, and you will be done (probably after you are done with your coffee). In this installation walkthrough, Visual Studio was installed from the downloaded .iso file.

After starting your installation, you will be greeted by a warm contractual warning and a couple of check boxes. If you are using the free download trial version, consider sending the Customer Experience Improvement Program a bit of usage information. If you are doing a demonstration on a client’s environment, that is their choice, and it is safer for you to not check this option and simply click Next when you are ready to continue. In the next window, if you are only going to be doing testing on your environment and not any coding, you can clear all of the optional feature boxes, or clear the Select All check box, and then click Install.

After you have completed the installation of Visual Studio and the installation of the updates, it will be time to start VS and begin creating a Visual Studio load test project.

From the Visual Studio Start Page, create a New Project, as shown in Figure 11-24.

Figure 11-24. Start by creating a new project.

Once you click the New Project link, a New Project window will open, as shown in Figure 11-25. You are going to create a Web Performance project.

Figure 11-25. Create a new Visual Studio 2012 project window.

Your load test will encompass many moving parts. The first thing you are going to create is a Performance Web Test (.webtest file). This file is the actual script that Visual Studio will use when it runs the load test. It is usually very easy to create a .webtest file, as all you have to do is click around within your website using Internet Explorer, and perform the functions that you want to test. By default, when you create your Visual Studio Project, a WebTest1.webtest file will be created and opened for you to start your script. For example, you might want to test Search by actually doing a search, or clicking around within your top-level site to test site functionality and response, upload a document that starts a workflow, or view a Microsoft Word document with your WAC server. You can create test sections that will not just test your farm, but are created to test different parts within SharePoint itself. Another test that should be tried, especially before you consider yourself finished with testing, is that you should start a full crawl and user profile synchronization while you are load-testing, and eventually, while you are stress-testing, your environment.

Before starting the creation of your Performance Web Test script, think about what you actually want to test. Once you think you know what you want to do, type your ideas into a spreadsheet and adjust as necessary. If you are going to be testing the upload of files, especially large files such as videos, create a script to back up your content databases and a script to restore your content databases after you have completed your test. You always want to have your test bed be exactly the same for each run of your testing; otherwise, you will never get valid results.

After you have documented your test, open up your Visual Studio solution and open your .webtest file. After opening the file, press Record, which should open Internet Explorer, as shown in Figure 11-26. You are now going to create the web test that the load test will use to see how many RPS your farm can handle. To keep the math simple, to help determine the number of RPS, this test is going to create a web test that is going to make only one page request.

Figure 11-26. An image of the pages that Visual Studio will use for its load test.

When you have completed recording your Performance Web Test, Visual Studio will run a test to make sure that your Performance Web Test parameters are actually valid. When Visual Studio has compiled your performance test, delete everything that is not a request to a URL. That means, for this example, keep only the requests to .aspx pages. For other testing scenarios, there may be a need to keep other requests, like client object model calls.

If your web test is failing, double-clicking within the Error Message cell will open a new WebTest tab and Visual Studio will execute your .webtest solution. This will show you where your web test has failed so that you can go back into your .webtest solution and fix the outstanding problems. After you have fixed all the failing issues, your test results should show Passed, similar to Figure 11-27. Save your web test and rename the WebTest1 to something more useful.

Figure 11-27. The Test Results show the successful completion of a Passed Performance Web Test.

Once all the issues have been verified as resolved and you have changed the Performance Web Test name, it is a good idea to give your performance test one last run because you will be using your performance test in your load test. As shown in Figure 11-28, after you select the properties of the Performance Web Test, you can add a specific user to impersonate while running the web test.

Figure 11-28. This image shows how to add a fixed user name and password to your web test.

Creating a valid performance test is the foundation for your load testing and stress testing. If you do not create a performance test that matches how your organization or clients will be using their farm, then you are not testing for a valid scenario and your load and stress testing will not be accurate representations of the real load. You must know how the farm will be used and what people will be doing to access their information to help you build out successful performance-, load-, and stress-testing plans. There is more on this topic in the Putting it all together section at the end of this chapter.

After completing the build of your performance test, you can now build your load test. The load test solution will allow you to set various parameters to test in your environment, such as the number of simultaneous users and what servers to monitor. Remember that the purpose of the load test is to determine the RPS that your environment can handle while staying within the green zone, of how many RPS your environment can handle before entering the red zone.

Based off the RPS requirements from the RPS worksheet, you are going to copy and paste the Performance Web Test that you created three times and rename each one based on the nomenclature in the Excel document. Your Solution Explorer should look similar to Figure 11-29.

Figure 11-29. An example of the Solution Explorer.

Next, add a new load test solution to the project. To create an empty load test, choose Add Load Test from the Project menu, as shown in Figure 11-30.

Figure 11-30. Adding a load test to your solution.

From here, the New Load Test Wizard opens to help you with creating your load test. Click Next to start the fun!

In the second screen (shown in Figure 11-31), the wizard will ask you for a load test scenario name and to select the Think Time Profile. This test is going to use the Do Not Use Think Times option. The think time is the amount of time the Visual Studio will use to pause between requests; for example, after your home page loads, this is the amount of time you spend thinking about where to click next. A zero think time maximizes the RPS for your performance test; think of it as a potential self-inflicted denial of service attack. This is another reason why you do not want to do load testing on a live production environment.

Figure 11-31. Setting the think times for the load test.

In the next window, where you determine the Load Pattern, this test is going to use a Constant Load of 1 concurrent user (see Figure 11-32). As you will see shortly, your one virtual user is going to be a very busy person. This is a workaround to the limits of using the demo version of Visual Studio 2012 Ultimate, which can have only up to 25 concurrent users. There is a demonstration of how to do a load test for more than 25 concurrent users in the Putting it all together section at the end of this chapter.

The next window (shown in Figure 11-33) allows you to select the Test Mix Model, meaning how you want your performance test to run. The first test mix model is a test mix based on the total number of tests for each virtual user. For example, you could create performance tests based on specific job functions and then assign a utilization percentage for that test. If the project management team spends 20 percent of their time uploading documents, 50 percent of their time updating lists, and 30 percent of their time reviewing dashboards, then you would create three separate performance tests (one test for uploading documents, one test for updating lists, and a final test for going between dashboard pages). This test model would be used when you are basing your test mix on transaction percentages from IIS logs. The second test mix model, based on the number of virtual users, would be used when you are basing the load test on the percentage of users running a specific test. The third type of test mix model is the Based On User Pace test mix model. This model will allow you to perform specific tests for a specific number of requests per hour until the load test is complete. The final test mix allows you to have the users conduct their performance tests in a specific order.

Figure 11-32. The Load Pattern window.

Figure 11-33. The Test Mix Model wizard page.

The next page is the Test Mix page. The test mix allows you to select the performance tests that you have already created for your load test. This demonstration will be using the tests created in the previous section, Creating your Performance Web Test. Refer to your RPS worksheet once again to determine the numbers that you will need to enter.

Click Add, select your test from the Available Tests section, and move it to the Selected Tests section, as shown in Figure 11-34.

Figure 11-34. The Load Test Wizard’s Add Test window.

After you have added your tests to the Test Mix, enter how many requests per hour each type of user will require. As shown in Figure 11-35, take the values from the RPS worksheet and enter them into Visual Studio.

Figure 11-35. The distribution of the load based on user type.

Basically, this test consists of having one virtual user make a request to the Staff home page 36,000 times an hour.

For the Network Mix (see Figure 11-36), select the appropriate network that your users will be employing to surf to your web server(s). You have the option to distribute the network load between different types of networks, in case your environment is used by remote offices on a T1 line and mobile users along with your local network users. If you are going to do any testing outside of LAN network testing, Network Emulation will have to be configured. You can read about how to set up Network Emulation in the article “How to: Configure Network Emulation Using Test Settings in Visual Studio,” at http://tinyurl.com/PCfromDC-Emulation.

Figure 11-36. Available options for load testing on different network types.

The next window for setting your Browser Mix (shown in Figure 11-37) should be pretty self-explanatory, especially after filling out your Network Mix. However, setting up the Counter Sets window is a bit trickier. The Counter Sets window is where you add all the servers that you want to monitor during the load test. If you do not have all of the Visual Studio updates installed, you will not have the same options available to you as presented here. By default, you will see only the local machine groupings of Controllers and Agents in the Preview section. For this example, you want to monitor the effects of the load on the servers in your SharePoint farm, and if you were doing a simulation that passed actual user names and passwords, you would want to monitor your authentication servers as well. To start, you will need the server names of the servers in your farm. Click the Add Computer button on the bottom of the monitor window to add a computer, and then add a SQL Server server name. There are predefined counter sets to monitor your servers. Select SQL, and because SQL is an application server, select Application as well. Continue to add all your SQL servers in the same manner. After you have added your SQL Server servers, add all your SharePoint servers. For the SharePoint servers, select the SharePoint 2010 WFE counter set because the counter set contains prebuilt filters to monitor specific criteria within SharePoint. Also, select IIS and Application counter sets because SharePoint servers use both of those server roles. Click Next to continue.

Figure 11-37. This window shows the counter set options for the servers in the farm.

This test is going to be timed. If you have not run through your site(s) using your performance test multiple times, and you are worried that your pages might return slowly, you would set the warm-up test duration to something that would allow your script to hit all of your webpages so that everything is ready for the load test. A warm-up test would also be a good idea if you want to bring up your CPU temperature slowly for the load test so that you do not shock the system too much, but primarily you add a warm-up test to load components into cache and memory before the actual test starts. A 5-minute warm-up time is usually a good starting point for most load tests.

In the Run Settings window (shown in Figure 11-38), set your Run Duration to 20 minutes. A 20-minute run time gives Visual Studio enough sampling data points of your environment, and running tests over 20 minutes will not provide any worthwhile changes to your test data. So don’t waste your time—keep your load tests to 20 minutes.

Figure 11-38. An example of the options for length of time used when creating the run settings.

After you have finished filling out your time parameters, click Finish to complete your load test solution. After clicking Finish, the Load Test tab should open. Now it is a good idea to go into your Solution Explorer and rename the LoadTest1.loadtest file to something a bit more practical and descriptive.

At this point, you can go ahead and click Start Test to begin your new load test, but you have not set your green and red zone thresholds. You should have your green and red zone limits already documented, so take your thresholds and put them into the Counter Sets so that you will receive a notification when you have breached a threshold.

The first threshold to set up will be the availability of RAM. Since you have added the Application type counter set to all the servers, modifying only the Available MBytes within the Memory counter category of the Application counter set (as shown in Figure 11-39) will set a rule that will be monitored for all the servers. Expand the tree to get to the Compare Constant that has already been created. Right-click Compare Constant and select Properties to set the Threshold Values. Set the alert so that you will be notified when the data point goes under your available memory threshold numbers, so keep the value of the Alert If Over set to False, and set your Critical Threshold Value to your red zone threshold value. Set the Warning Threshold Value to the upper end of your green zone threshold value.

Figure 11-39. Setting the Threshold Values of the Available MBytes.

After setting up your memory thresholds and warning, follow the same procedures for the Server Latency (Avg. Response Time), CPU Utilization (% Processor Time, as shown in see Figure 11-40), and Average Page Load Time (Avg. Page Time).

Figure 11-40. Location of the % Processor Time category.

The settings for % Processor Time and Available MBytes have threshold rules by default. To create the threshold rules for Avg. Response Time and Avg. Page Time, right-click the appropriate counter, as shown in Figure 11-41, and select Add Threshold Rule. Set the Compare Constant values to the appropriate threshold value. The option to use Compare Counters is used when you want to compare the current counter against other performance counter values.

Figure 11-41. Location of the Avg. Page Time and Avg. Response Time.

Now that you have set up parameters for your test, it is time to run your load test. While the load test is running, remember that eventually you will want to kick off a search crawl and start a User Profile Service (UPS) synchronization. While you are load-testing your farm, open an Internet browser and take a look at the sites for yourself. Open Developer Dashboard (this will take up CPU utilization), and the other tools mentioned earlier in the chapter and see for yourself what your load test does to the performance of your farm. Once your load test is complete, address the errors that were found and then run the test again. If you are running the test with an NLB, make sure that there is actually a balanced load between all your web servers. As you review the test results of this demonstration, notice that the farm had an RPS of approximately 25.5 (see Figure 11-42).

Figure 11-42. Results of the load test.

Taking a look at the results, the RPS is equal to 25.5, while according to the RPS worksheet, there should have only been 10. As previously depicted in Figure 11-23, while the load test is going on, SharePoint is making its own requests as well, and over the period, SharePoint increased the RPS by 150 percent.

After completing the load test, it will be time to draw up the plans for how to attack the reallocation of your server resources. In a physical world, you will not be able to do too much when it comes to adding processors, but there is always the option of adding web servers or an NLB to help distribute the workload. One thing to be aware of while testing with multiple web servers that are load balanced is that depending on how you have the Affinity of the NLB cluster set up, your load test might hit only one of your web servers. To get around this, you can either change the settings of your NLB or create a Performance Web Test that uses server names instead of URLs. There is more information on load testing in the Putting it all together section at the end of this chapter.

You have already determined your red and green zone envelopes, so you know where your farm is happiest. Now slowly increase the load on your environment until parts of your environment start to fail (see the example in Figure 11-43).

Figure 11-43. This error happens when the server resources are low and the web server cannot keep up with demand.

In the Creating your Performance Web Test section earlier in this chapter, you created a web test for conducting your load test. For the sake of consistency, you are going to use the same Performance Web Test for your stress test as well, but instead of using one concurrent user, you are going to add users to the test until your environment is stressed beyond capacity.

Just like before, you are going to create a new Load Test Project (Project | Add Load Test). Once the New Load Test Wizard has opened, click Next. Give your scenario a useful name, and select Do Not Use Think Times.

Now this is where things will start to differ from the creation of your load test in the previous section. Because this demonstration is using the demo version of Visual Studio 2012 Ultimate, you can have a maximum of only 25 concurrent users. This is fine because you did your stress test using only one, very busy, concurrent user. The problem with this method is that you are doubling your RPS for every user added, so adjust the requests per hour accordingly in the Test Mix window. As shown in Figure 11-44, this example will increase the load on the servers by 10 percent every 2 minutes to a maximum of 25 users or a 250 percent increase in RPS.

Figure 11-44. Step Load test settings.

In the next window (shown in Figure 11-45), create a Test Mix Model based on user pace. For the test mix, break down your numbers from the Creating your load test section earlier in this chapter and only use 10 percent because you are starting the stress test with 10 concurrent users.

Figure 11-45. Requests per user per hour.

Finish up the rest of the settings the same as in the Creating your load test section, except increase your Test Run Time from 20 minutes to 32 minutes to test all the increases in concurrent users.

If the requirement for demonstrating a load test for your boss is below 250 concurrent users, then you should try using Visual Studio 2010 Ultimate. The maximum number of concurrent users for the Visual Studio 2010 trial version is 250.

Download the .iso file from http://tinyurl.com/PCfromDC-VS2010iso, and install the service pack from http://tinyurl.com/PCfromDC-VS2010-SPiso. If you are going to run this setup on a Windows 8 or Windows 7 environment, install the Forward Compatibility Update from http://tinyurl.com/PCfromDC-VS2010CU. To export documentation from your test sessions, you should have Office Professional Plus 2010 installed (http://tinyurl.com/PCfromDC-Office) as well as the service pack for Office 2010, which you can get through Windows Update.

If your oss wants you to demo a load test for more than 250 concurrent users, you can download a 90-day trial version of the Visual Studio Team System 2008 Team Suite from Microsoft to run your load tests. You can download the Visual Studio Team System .iso file from http://tinyurl.com/PCfromDC-VS2008. Download and install the service pack after you install Visual Studio Team System 2008. You can download the .iso file from http://tinyurl.com/PCfromDC-VSTSsp1.

The installation of Visual Studio 2010 and Visual Studio Team System 2008 is very similar to the installation performed for Visual Studio 2012 Ultimate in the “Setting up Visual Studio 2012 Ultimate” section earlier in this chapter, except that you just want to install the product using the default settings.

After you create a web test, Internet Explorer should open and allow you to start recording your web session. If you are using Visual Studio Team System 2008 and the recording window does not pop up as it did for Visual Studio 2012, some troubleshooting will be required. To use Visual Studio Team System 2008 with Windows 8, close all instances of Internet Explorer, and then go into the registry and delete following entries located at

For more Visual Studio Team System 2008 troubleshooting help, visit http://tinyurl.com/PCfromDC-Recorder and read “Diagnosing and Fixing Web Test Recorder Bar Issues” by Michael Taute.

If you decide to run Visual Studio Team System 2008, there is one more modification that might be helpful to avoid a System.OutOfMemoryException error. Try modifying the VSTestHost.exe.config file, which by default is located in the C:Program Files (x86)Microsoft Visual Studio 9.0Common7IDE folder. Remember to make a backup of the file prior to modifying the .config file. Within the <runtime> tag, add <gcServer enabled=”true” />.

The next step is to create your performance test by creating a web test, and then going to the sites that Contoso has specified in its instructions. By surfing through the company’s sites and recording the URLs, you will be able to not only grab the URLs to test but also the parameters passed through the URLs. Once again, when you are done with creating your web test, delete all the extra posts so you are only sending requests to the .aspx pages, as shown in Figure 11-54.

Figure 11-54. The Performance Web Test sites and parameters.

One thing to be aware of is the number of requests that the performance test is making. It is not a coincidence that there are 10 requests for this; when it comes time to create the load test, it will be easier to do the math.

After you create your performance test, run it and have your test validated. The validation is useful because you do not want to run 20 minutes of invalid web testing, but it also allows you to look at the performance numbers returned from your test. After running the initial web test, Figure 11-55 shows that there is a huge discrepancy in total time between the search farm and the rest of the farm. After running the test 10 more times just to be safe, the issue still remained.

Figure 11-55. Metrics after running the Performance Web Test.

After going through the Search Farm event viewer, there were issues with the SharePoint server communicating with its SQL server. While running a ping test between the two servers, one of the NICs on the SQL server would turn off and on at random intervals. So after replacing the NIC and rerunning the performance test, our numbers improved to within expected times, as shown in Figure 11-56.

Figure 11-56. Total time for all sites are within the expected time.