Friday, December 1, 2017

Visual Studio Profiler on Server Environments

Visual Studio Profiler is a most valued tool for analyzing your Microsoft.NET application’s runtime performance. You can get the application’s performance with respect to CPU, Memory, Disk, Network and many more.  This is hosted as part of Visual Studio and using the same is a breeze. You’ve to opt the Analyze Menu to start analyze your application.

It works on top of the native PerfMon.exe, which captures a native applications runtime statistics. As .NET applications are compiled to MSIL (which are converted to Machine Code at runtime by JIT), profiling it directly through PerfMon.exe won’t be giving you the mappings between the profiled applications and its Source .NET Code (C#/VB.NET).  This is where Visual Studio Profiler comes in; fills the gap between the MSIL and Machine Code boundaries. It tracks the runtime applications to its source .NET code while you generate the profiler reports.


But what if you want to Analyze your deployed application on servers (where probably no Visual Studio gets installed). In those scenarios you can use the Visual Studio Standalone Installer. The entire profiling is then done through command line only. The profiling process can be categorized in below five steps.


1. Settingup Profiler (Onetime per environment)

  • Setting up Symbol Server Path (In environment variables)

set _NT_SYMBOL_PATH=srv*C:\CLRSymbolFiles*http://msdl.microsoft.com/downloads/symbols

  • Setting up Profiling modes

Trace Mode:
VsPerfCLREnv /GlobalTraceOn

Sampling Mode:
VSPerfCLREnv /GlobalSampleOn


  • Adding extra environment variables

e.g. To make the Trace Mode work

CORECLR_ENABLE_PROFILING=1
CORECLR_PROFILER={2CCFACEE-5E60-4734-8A98-181D93097CD9}

e.g. Adding 64-bit profiler to PATH variable, for using 64-bit Profiler to profile 64-bit applications
(C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Performance Tools\x64)

2. Instrumenting the Binaries for Profiler (Onetime, Or anytime new binaries deployed)

Eg:
VSInstr "C:\Test \TestApp.exe”
VSInstr "C:\Test \TestApp.DLL”

3. Starting the Profiler (Every time when you are about to start profiling the application)

VsPerfCLREnv /TraceOn
 
VsPerfCmd /start:trace /output:"C:\Test\TestApp.vsp"

VsPerfCmd /start:trace /output:".\TestApp.vsp" /user:DOMAIN\ServiceAccount /crosssession

If you’re profiling a windows service running under a different account or profiling ASP.net application, worker processes, /user /crosssession switches should be provided.

**Now launch the application and perform actions

4. End the Profiler (When you want to stop profiling the application)

VSPerfCmd /shutdown
VSPerfCLREnv /off

5. Analyze the profiler reports


The VSP reports generated can be directly opened in Visual Studio for analysis.
It should be also noted that, Instrumented Profiling can generate large VSP files (In GB Size) which are quite normal.

Sample project can be downloaded from here.




Advanced Profiling Topics:

Since instrumentation profiling requires large VSP files, we can opt Sampling to analyze the application, which generates reports of less size. But Sampling cannot be used to get timing data.

Even with instrumentation profiling, we can instruct our application to profile certain part of the application as needed, which reduces the profile data and the size of the VSP file. The below links describes these concepts in detail:

Limiting the Data Crunch from Trace Profiling
Advanced instrumenting with the VSTS profiler
Visual Studio Team System 2005 Performance Tool FAQ