TN_1207: Profiling services basics

Ian Huff, Software Design Engineer
Microsoft Corporation

Included in the new Visual Studio Team System Developer (and Team Suite) edition is a powerful new performance profiler. This tool will allow you to profile native and managed executables, assemblies and ASP.NET websites. You can profile in both sampling mode, where you capture program state in some periodic cycle, or in instrumentation mode, which inserts code into the assemblies being profiled to capture all function entry and exits. While we expect that most users will be profiling standalone applications with the profiler, we realize that more and more people are using remote services and that they want to be able to profile them. This TechNote will take a look at the basic understandings and tools needed to profile a service.

Understanding data collection:

Before you can profile a service you need to have some understanding about how the profiler collects data. The profiler has a monitor running that grabs data from various runtime processes located in the assemblies that you are profiling via globally shared objects. The monitor is then in charge of outputting all that data to the report file. There are different types of runtime libraries for managed code and for instrumentation and sampling modes. Typically, the running processes only get one chance to connect to the monitor or else they will never be able to. The point of this is that any instrumented target binary that executes before the monitor is up and running will never be able to provide data to the monitor without restarting.

Getting the runtimes in:

To insert the runtimes for managed CLR profiling you must have specific environmental variables set on your target application to be able to profile it. By using the VSPerfCLREnv tool (all the command line tools are installed to Microsoft Visual Studio 8\Team Tools\Performance Tools) you can set these variables for any process or turn them on or off globally.

For sampling mode we use CreateRemoteThread to get the runtime libraries in. The limitation with this is that it does not work across Terminal Services sessions and most services run in session zero while typical user sessions are non-zero. In this case the shared objects that the runtime uses to communicate with the monitor will fail to open and you will not be able to collect profiling data. To work around this we need to grant the target processes access to the monitor’s shared objects. We’ve provided the monitor with a /USER switch that lets us do just that. For example if the service runs as “LOCAL SERVICE” you would use the following line to start up the monitor:

VSPerfCmd /start:trace /output:data.vsp /user:"LOCAL SERVICE"

Now that we have looked at a few of the issues that we have to deal with when profiling services we can take a quick walkthrough of profiling a managed service using both instrumentation and sampling.

Profiling a managed service using sampling – walkthrough:

The first step in this process is to install the service.  Do not start the service; as you need to have the magic environment variables set before starting.  To do this, use vsperfclrenv /GlobalSampleOn

vsperfclrenv /globalsampleon

Now you need to restart your service to detect the new settings, note that this may

require a reboot of your machine. After the reboot, we need to start the profiling monitor up in sampling mode.  Make sure you include the service account in the /USER option so that we can connect. Also we need to specify the output report file (import_sample.vsp) that we will write our data to.

vsperfcmd /start:sample /output:import_sample.vsp
/user:"LOCAL SERVICE"

Now you can start the service.  The environment variables will cause the CLR to load the Visual Studio runtime for managed profiling.  The monitor is now running, and it is set up to allow the LOCAL SERVICE account to connect. You can verify that you have the correct settings by running:

vsperfcmd /status

Then just look under the “Users with access rights to monitor” section for the following id:

NT AUTHORITY\LOCAL SERVICE (S-1-5-19)

Now start the service from the services snap-in as usual. After starting it, we want to attach the profiler before we run our profiling scenario.

vsperfcmd /attach:ExampleService.exe

Now you need to run whatever scenario you want to profiler your service with. Once you have finished your scenario we could use the /detach option to stop profiling. Or if we want to profile to the end of the service we can just use the shutdown command:

vsperfcmd /shutdown

Now you will have created a .vsp report file that you can open up in the IDE for analysis. When analyzing it you may want to use function view, right-click and choose “Group By Module” so that you can look at just your code as opposed to all the CLR marshalling, remoting and serialization code that was collected.

Profiling a managed service using instrumentation – walkthrough:

Profiling a service with instrumentation is only slightly different from sample profiling.  First of all, and most importantly, the Visual Studio profiler's CLR component uses a different CLSID for trace profiling, so once again it's necessary to set up the environment properly, and reboot the system:

vsperfclrenv /globaltraceon

When trace profiling, you must instrument the code you wish to profile.  To do this just use the vsinstr tool on all the binaries that you want to collect data on.

vsinstr ExampleService.exe

Next we need to start up the collection monitor.  Remember, the monitor must be started before the instrumentation runtime attempts to connect.  The runtime will attempt to connect automatically when the service is started.

vsperfcmd /start:trace /output:example.vsp

Then you can just start the service as you normally would.  Here is where you will run whatever service scenario you are looking to profile.

vsperfcmd /status

After running your scenario you need to first stop the service and then shutdown the monitor using VsPerfCmd.

vsperfcmd /shutdown

Now, just as with sampling, you will have a VSP report that you can open up in the IDE for analysis. Notice that with instrumentation we profiler from startup so you can see data in the services OnStart method.

You can use the techniques and walkthroughs in the TechNote to help get you started with profiling services using the profiler included with Visual Studio Team System.