Insights

of |


Web Service Profiling Using Visual Studio

August 18, 2010

Abstract

Performance is a priority in any application, and it has become increasingly important in web applications, where there are already unavoidable delays associated with transferring data over the internet. Web applications should be as efficient as possible to minimize the time it takes for a response to reach the client, whether that client is a user sitting at his computer or another business application.

To determine how efficient your application really is, you need to be able to see how the application flows during execution. For example, you need to know which functions are being called, how often they are called, how execution flows from one function to another (the call stack), etc. Once you have this information, you can look for areas where algorithms and logic can be fine-tuned to result in more efficient code.

To assist in determining application performance, Visual Studio includes a tool called Profiler that can be used to locate areas of your application where a lot of execution time is spent, which are areas that would likely benefit most from improvements in performance. There is already a lot of information on the internet that explains the basic use of Visual Studio’s Profiler, including examples with small sample applications you can use to test. However, there is not much information on profiling web services, including the limitations involved. The focus of this article is to address the topic of profiling web services using Visual Studio’s Profiler.

Because web services are not stand-alone applications but instead require an incoming request to initiate execution, a separate mechanism must exist for making web service requests in order to test your web service application. This article assumes you already have a method for initiating calls to your web service, such as a web test.

Types of Profiling

There are two types of profiling that you can do using Profiler: sampling and instrumentation. Sampling, as the name implies, involves taking a snapshot (or sample) of an executing application at predetermined intervals. Instrumentation is a much more involved process that actually inserts probes at the beginning and end of each function in the assembly to be profiled, which it uses to track the execution of the application.

Because it is not just pulling information at timed intervals, instrumentation produces a great deal of data, to the point that it can easily become overwhelming. Because of this, sampling is normally the first profiling method used. Once you have used sampling to determine a specific part of the application on which to focus, instrumentation can then be used on that area to obtain more detailed information.

Sampling is the only method that can be used when profiling web services through the IDE, which is what this section of the article will cover. There are command line tools that can be used for instrumentation, and that will be covered later in the article.

Sampling an Application Via the IDE

The process we will follow for profiling the web service is similar to debugging a web service via a separate web test. We will attach to the IIS process (w3wp) and then execute the web test that calls the web service through IIS (i.e. via http://localhost/[WebServiceName].asmx).

  1. Open the solution that contains the web service project you want to profile. Select Analyze → Launch Performance Wizard.
  2. On the first page of the wizard, select the web service project you wish to profile.
  3. The second page of the wizard prompts you to select a client for the profiler to launch at execution. Because we will be attaching to the IIS worker process and initiating the tests ourselves, we do not need the profiler to launch an application. You can just select Internet Explorer for this option.
  4. On the third page, select Sampling as the profiling method.
  5. On the final page, click Finish. This will create a performance session and open the Performance Explorer. You will see the newly created session in the Performance Explorer. Your web service project should be listed in the Targets folder, and there will also be a Reports folder that will be empty at the moment.
    6. As mentioned above, the profiler will sample the applications at specific intervals. The frequency is set in the properties of the performance session.

  6. Right-click on the session name, and select Properties to open the Property Pages dialog.
  7. Select Sampling in the left pane. The Sample event and Sampling interval will be displayed at the top of the right pane. As you can see, there are four choices for the sample event: Clock cycles, Page faults, System calls, and Performance Counter. Clock cycles is the most commonly used selection. However, you can use the other options if they fit your specific needs. For example, if you are experiencing memory issues, you may choose to use Page faults as the sample event. For the purposes of this article, we will use Clock cycles
    8. You may also want to adjust the sampling interval. For example, the default is 10,000,000; in our experience, we have found this to be too infrequent - we do not get enough data to get a clear and accurate picture of my application’s execution. We have found that 100,000 is a good interval for our application. This will vary according to your application and your hardware, so adjust this as needed for your situation. Remember that the lower the interval value is, the more often it will sample your application, and the more data you will extract. This also means that the profiling will take longer to complete and the reports that analyze the data will take longer to load.

    Once the sample event and interval are set, we are ready to begin sampling. We first need to attach to the IIS worker process (w3wp).

  8. Right-click on the session, and select Attach/Detach.
  9. Select w3wp in the list, and click Attach. (If the process is not already running, you can start it by navigating to your web service, i.e. http://localhost/[WebServiceName].asmx in your web browser. Also, if you do not see the process in the list, you may need to check Show processes from all users.)

You can now initiate the web test that calls your web service through the url above. When the test completes execution, return to the performance session to detach from the process. The easiest way to detach is to click the stop button on the Performance Explorer toolbar. Alternatively, you can follow the steps you used to attach to the process but instead click Detach once you have selected w3wp. Either way, when you detach from the process, it will be ended automatically.

Once you detach from the process, the profiler will automatically analyze the data collected and open the performance report. This process may take several minutes, depending on the amount of data collected. (There will be a progress bar displaying the status of this process.)

You can now use the report to locate those portions of your code that spent the most time executing. Again, there is already a lot of information on the internet regarding the report and how to interpret it, so I will not spend too much time here on it (see the links at the end of this article). Instead, I will give a brief overview of the data that is shown.

First off, there are two terms used in the report that you should be familiar with: inclusive and exclusive. For example, if you use the drop-down at the top of the report to switch to the Functions view, you will see each function that was part of the sampling, along with columns such as Inclusive Samples and Exclusive Samples.

  • Inclusive means that at the time the sample was taken, the executing code was either in this function or was in a function called by it.
  • Exclusive means that at the time the sample was taken, the executing code was actually in this function.

This is the same idea used on the summary page, which lists functions causing the most work and functions doing the most work. Functions causing the most work are those with high inclusive sample counts, meaning they are calling a lot of other functions (which in turn might also call others, all of which would be included in the function’s inclusive sample count). Functions doing the most work are those with high exclusive sample counts, meaning execution was often occurring in that actual function during execution. Both of these are useful, but it is important to understand the difference between the two when analyzing the data.

The Functions view is very useful when analyzing the data. Once you pinpoint a function that you would like to investigate further, double-clicking on it from the Functions view will take you to the Caller/Callee view for that function. This allows you to see what functions called this function, and what functions were called by this function. You can double-click on any function in this view to move further up or down the call stack.

Instrumenting an Application Via the Command Line

Once you have sampled your application and you have identified an area that needs further analysis, you can instrument that section. As mentioned above, this cannot be done via the IDE. (You will notice that if you go to the properties of the performance session and change the type from sampling to instrumentation, the Attach/Detach option is no longer enabled for the session.) However, there are command line tools that can be used to do this.

There are 5 utilities that you will use for this process:

  • VSInstr
  • VPPerfClrEnv
  • VSPerfMon
  • VSPerfCmd
  • VSPerfReport

All of these are located in the Visual Studio installation directory under Team Tools\Performance Tools. Open a command prompt and navigate to that directory. You can then run the following commands.

  1. Instrument the binary:
    VSInstr [full path to the dll to be instrumented]

    For example:
    VSInstr c:\MyWebServiceProject\bin\DataLayer.dll

    As you can see from the status as this process runs, it first creates a backup copy of the dll and then instruments the dll that will be used by the application.

  2. Set Windows environment variables:
    VSPerfClrEnv /globaltraceon

    After this step, you must reboot your computer for this change to take effect.

  3. Create and start the session:
    VSPerfMon /trace /output:[session name].vsp /user:"[user name for IIS worker process]"

    For example:
    VSPerfMon /trace /output:InstrumentSession1.vsp /user:"NETWORK SERVICE"

    You can determine the user name for the worker process by opening Task Manager and finding the User Name listed for w3wp.exe.

    4. At this point, you can run your web test as normal. You do not need to attach to a process. The above steps will ensure that any activity involving an instrumented assembly will be logged. When the web test has completed, continue with the following commands. You will have to open another command prompt, as the above command will run in the first window during the collection process.

  4. Stop the IIS worker process:
    iisreset /stop
  5. Stop the session and save the collected data:
    VSPerfCmd -shutdown
  6. Create the report:
    VSPerfReport [session name from above].vsp /summary:all /packsymbols

You can restart IIS at any time once the session has stopped and the report has been generated using the iisreset /start command.

You can then open the report in Visual Studio for analysis. To do this, return to Visual Studio and open the Performance Explorer. If a performance session already exists, you can add the report to that session by doing the following:

  1. Right-click on the Reports folder
  2. Select Add Report
  3. Select the report in the Add Report dialog

Alternatively, you can open the report by selecting File → Open → File, and selecting the report in the Open File dialog.

Again, it may take a few minutes for Visual Studio to analyze the data and open the report. Once the report is complete, viewing it is essentially the same as viewing the report from sampling. Note, however, that the information presented is a bit different. For example, on the summary view , instead of showing the functions causing and doing the most work based on sample counts, it shows the functions that were called the most, functions that did the most individual work (largest exclusive times), and functions that took the longest to complete (largest inclusive times). Although the data presented in the report is based on actual time instead of sample counts, the structure of the report is the same and the views function in the same manner.

When you are finished with your instrumentation session, the global variable that were turned on in step 2 above need to be turned off using the command VSPerfClrEnv /globaloff. Once again, you will have to reboot your computer for this change to take effect.

Summary

Whether you are using sampling or instrumentation to profile your application, Profiler allows you to gather valuable data regarding the execution of your application by showing you the areas of your application that take up significant execution time. Once you have pinpointed these areas, you can look for ways to optimize them and improve your application’s efficiency. Once you do, it may even be valuable to profile your application again to see how the execution has changed and to find new areas to improve.

Links to Related Information

If you would like more information on profiling using Visual Studio, please visit the following sites:

of |