Profiling ASP.NET Applications via ASP.NET Development Server

Sample Application

Requirements

1. Compiling the Application

2. Profiling the Application

Notes on Using the Allocation Profiler

In our description we will use a sample application called XMLTrace. It parses an XML file and displays its contents and structure. You can find the application sources in the following folders:

On Windows Vista and later, AQTime samples are located in the <Users>\Public\Documents\AQTime 8 Samples folder. On other operating systems, the samples reside in the <Documents and Settings>\All Users\Documents\AQTime 8 Samples folder.

We will use the Visual Basic 2005 sample located in the <AQTime Samples>\Managed\VS2005\XMTrace\VB folder. To run this sample application, you will need Microsoft Internet Explorer 6.0 or later.

Profiling ASP.NET applications requires 32- or 64-bit editions of Windows XP, Windows Server 2003 or later with Internet Information Services ver. 4.0 - 7.5.

Open the sample project <AQTime Samples>\Managed\VS2005\ASP.NET\XMLTrace\VB\XMLTrace.sln in Visual Studio and build or publish it. See How AQTime Profilers Use Metadata and Debug Information to decide whether to include debug information. To learn how to compile ASP.NET applications with debug information, see Compiler Settings for ASP.NET.

To build the project, select Build > Build Web Site from the Visual Studio menu.

To publish it, select the Build > Publish Web Site menu item and uncheck the “Allow this precompiled site to be updatable” box in the ensuing Publish Web Site dialog. Select also the “Emit debug information” check box in the dialog to generate debug information files.

When you build an ASP.NET application created as an ASP.NET Web Application project, Visual Studio creates one common assembly for the application and puts it to the bin subfolder of the folder where the application project resides.

When you compile an ASP.NET application created as an ASP.NET Web Site project (note that the XMLTrace sample being considered is exactly an ASP.NET Web Site project), Visual Studio organizes the application code into several temporary dynamic link libraries whose location and names are changed from one compilation to another. Since ASP.NET Web Site projects are dynamically compiled by ASP.NET on the server when users request the application’s web pages, Visual Studio does not create output assemblies with the application code in the project’s folder when compiling the application. The assemblies are temporary and Visual Studio usually puts them along with debug information files (if you compile the application with debug information) to the temporary subfolders of the <Windows>\Microsoft.NET\Framework\<Framework Version>\Temporary ASP.NET Files folder. The library name includes the source file name and some hash value and looks like App_Web_xmltrace.aspx.cdcab7d2.dll. Since the names are changed, you have to include new modules in your AQTime project every time you compile your application, and there is no guarantee that you will add all application modules, since their names and locations are defined by Visual Studio.

To avoid these problems, you can publish your ASP.NET Web Site project before profiling it (you should publish your ASP.NET application every time you compile it). The folder that you will specify for publishing will contain all DLLs generated for your ASP.NET application. It is recommended that you publish your project to the folder that is used as a virtual directory. If you publish it to another folder, you should specify that folder as a source folder for your virtual directory.

If you do not publish the project, you can still profile all application modules. To do this, add any module to your AQTime project and check the Entire .NET Code option in the Setup panel.

To profile your ASP.NET application with AQTime using the ASP.NET Development Server:

• Open the application’s library modules from the folder that you published your application to in AQTime’s Setup panel. If you did not publish your ASP.NET project, enable the Entire .NET Code option.

  Note:

  As it has been said above, when you build your ASP.NET project without publishing it, the location of the resulting assemblies depends on the project’s type: If you use an ASP.NET Web Application project, you can find the resulting assemblies in the bin subfolder of the project’s folder. If you use an ASP.NET Web Site project, you can find the resulting assemblies in the temporary subfolders of the <Windows>\Microsoft.NET\Framework\<Framework Version>\Temporary ASP.NET Files folder.

• Select Normal from the Profiling Mode dropdown list box on AQTime’s Standard toolbar.Select Normal from the Profiling Mode dropdown list box on Visual Studio’s AQTime toolbar.Click Normal on RAD Studio’s AQTime Profiling Modes toolbar.

• Select Run > Parameters from the main menuAQTime > Parameters from the Visual Studio menu and specify an ASP.NET Development Server as a host application and define command line parameters to it in the Run Parameters Dialog (for Normal Mode). The name and location of the server’s executable depend on the Visual Studio version you use and on .NET Framework’s version used by your ASP.NET application.

  For example, if you use Visual Studio 2012 and the profiled application uses .NET Framework 4.5, specify the following executable as the host application:

  <Program Files>\Common Files\Microsoft Shared\DevServer\11.0\WebDev.WebServer40.exe

  For information on the location of the server’s executable for other Visual Studio and .NET Framework versions, see MSDN library (the online version is available at http://msdn.microsft.com).

  A command line defines the port number, physical path and virtual path of the profiled ASP.NET application and has the following syntax: /port:<port_number> /path:<physical_path> [/vpath:<virtual_path>] where:

  • <port_number> - the number of an unused port, between 1 and 65535.

  • <physical_path> - a valid directory name where the ASP application is located.

  • <virtual_path> - [optional] a virtual path or application root in the form '/<app name>'. The default value is '/'.

  For instance, for the sample project the command line would be:

  /port:1169 /path:"C:\Work\AQTime 8 Samples\Managed\VS2005\ASP.NET\XMLTrace" /vpath:"/XMLTrace"

• Select the desired profiler and press  Run to start profiling.Select the desired profiler in the AQTime > Profiler menu item or from the Profilers box on the AQTime toolbar. Then choose AQTime > Run (or select Debug > Run while one of AQTime panels is active) to start profiling. AQTime may ask your permission to restart the IIS Admin service. Answer “Yes” to this question.

• Launch Internet Explorer and open the http://localhost/XMLTrace/VB/xmltrace.aspx file in it. Do not open this page from the Internet Information Services window with the Browse command.

  Perform the profiling as your needs dictate.

  When you are profiling an ASP.NET application, the Event View panel displays events that occur both in the ASP.NET process and in the profiled application. One important thing about this is that all displayed general events occurred in the ASP.NET process, all .NET specific events occurred in the profiled ASP.NET application. (For detailed information on general events and .NET specific events, see Event View Panel).

• To obtain the results, select Run > Get Results from AQTime’s menu.select AQTime > Get Results from the main menu of Visual Studio.select AQTime > Get Results from RAD Studio’s main menu. Another way to obtain the results is to create an action that will “tell” AQTime to generate the results. See Getting Results During Profiling for more information.

• To terminate the profiler run, select Run > Terminate from AQTime’s main menu or press Terminate on the Standard toolbar.select AQTime > Terminate from the main menu of Visual Studio.select AQTime > Terminate from RAD Studio’s main menu.

Your application may contain classes inherited from the System.Web.UI.Page or System.Web.HttpApplication class. If you include these inherited classes in profiling tasks and profile your .NET application with the Allocation profiler, you may note that AQTime reports that no instances of the inherited classes are created.

This happens because the ASP.NET process does not create instances of your classes, which are inherited from System.Web.UI.Page or System.Web.HttpApplication. It creates instances of temporary classes that are inherited from your classes. Since your classes are not created, the profiling results are empty for them. However, the Allocation profiler automatically includes temporary classes in profiling tasks and traces the creation and deletion of their instances. By viewing profiling results for temporary classes, you can see how the application used your classes during the profiler run.

The names of temporary classes inherited from System.Web.UI.Page have the following format: 

ASPXFileName_aspx,

where ASPXFileName is the name of the .aspx file (excluding the file extension) that refers to your class. For instance, the XMLTrace sample application includes the XMLTrace.aspx file that refers to the XMLTraceForm class defined in XMLTrace.aspx.cs. The name of a temporary class inherited from the XMLTraceForm class will be XMLTrace_aspx.

The names of temporary classes inherited from System.Web.HttpApplication have the ASAXFileName_asax format. For example, the XMLTrace application includes the Global.asax file that holds a reference to the Global class defined in Global.asax.cs. The name of a temporary class inherited from Global will be Global_asax.