dotMemory 2020.3 Help

Profile Web Application on IIS Server

Typically, determining performance issues in a web application is required when it is already running on a server. The table summarizes all possible options of profiling the application:

Pros Not cons but features
Local profiling
  • Easy to configure/use: you profile via the dotMemory GUI

  • dotMemory must be installed and run on the server, which may be impossible due to security restrictions, absence of GUI, etc

Profiling via console tools
  • No network communication required

  • Ability to create a number of predefined profiling configs and run them on demand

  • The console tools must be copied to and run on the server

  • Resulting snapshots must be manually copied from the server to the machine with dotMemory

Memory dumps
  • Nothing should be installed to the server

  • No profiling overhead

  • Memory dumps contain less data than dotMemory snapshots

Local profiling

Local profiling

Typically, local profiling is used when you need to profile the app that is hosted right on your (developer's) machine or on some testing environment, which doesn't impose any security/performance restrictions.

To locally profile a web app hosted on an IIS server

  1. Install dotMemory on the server.

  2. Run dotMemory as a standalone application. The dotMemory Home window will open.

  3. In the right panel, select Local.

  4. In the central panel, in Profile Application, select IIS.

  5. In the right panel, in Application Options, select Open URL and specify the URL of the profiled application. If you do not do this, dotMemory will start profiling of the first running application pool it'll be able to find.

  6. In the right panel, in Profiler Options, specify profiling type.
    For more details on profiler options, refer to the Profiler Options section.

  7. If you want dotMemory to start collecting the stack trace allocation data* right after the profiling session starts, select the Start collecting allocation data immediately option in the right panel.
  8. Optionally, if you are going to control profiling session (take snapshots, end session, and so on) using the API (rather than the Controller window), select Control profiling via API. For more details on how to control profiling using the API, refer to the Control Profiling Session with API chapter.

  9. Click Run. Note that after you do this, the IIS service and, as a consequence, the profiled application pool will be restarted.

  10. Take snapshots. For more details on how to control profiling session, refer to Control Profiling Session (if you control profiling manually) or to Control Profiling Session with API (if you control profiling using the API).

  11. After you collect the snapshot(s), click Detach on the Controller window to detach the profiler from the application pool.

  12. Analyze the collected snapshots.

Profiling via console tools

Profiling with console tool

Console tools are the best if you need to automate profiling: for example, you should profile your web app from time to time. Another possible scenario is when you don't have access to the server but some other person does, so you can provide them with profiling tools and a batch file.

How does it work? In short, you copy console tools to the server and either run the app under profiling (the app pool will be restarted) or attach the tool to the running application pool w3wp.exe. Then you can get snapshots by sending special commands to stdin.

To profile a web app on an IIS server using console tools

  1. Download the zip archive with the ConsoleProfiler.exe tool and copy/unpack it to the server.

  2. Now, you have two options for getting a memory snapshot:

    • Attach dotMemory.exe to the running application pool and instantly get a snapshot:

      dotMemory.exe get-snapshot 1234 --save-to-dir=C:\Snapshots
      where 1234 is the process ID of the corresponding w3wp.exe process.
      Tip: To get the ID, in IIS Manager, open the required server. On Worker Processes page, you will find the list of running workers and their IDs.

    • Run the application pool under profiling (if the pool is already running, it will be restarted):

      dotMemory.exe start-iis --trigger-timer=30s --open-url=localhost/myapp --use-browser=Chrome
      where --open-url=localhost/myapp is the URL of your application. In case you've chosen to run the app pool, you cannot instantly get a snapshot. Instead, you should:

      • get a snapshot by condition: for example, when --trigger-timer=30s is specified, snapshots are taken each 30 s

      • get a snapshot by sending a command to stdin: ##dotMemory["get-snapshot"]

      • get a snapshot on process exit (for example, Recycle app pool in the IIS Manager)

    For more details on how to work with the dotMemory console profiler, refer toUse dotMemory Command-Line Profiler.

  3. Copy the resulting snapshot to the computer with installed dotMemory and analyze the snapshot.

Memory dumps


What if, for some reason, copying and running third-party tools on the server is not possible at all. Well, then your last resort is memory dumps. It can be taken with a number of tools, with the two most popular being Task Manager (comes with the operating system) and Process Explorer.

To profile a web app on an IIS server using memory dumps

  1. On the server, take a memory dump using the Task Manager or Process Explorer tool. When creating a dump of a 32-bit application with Task Manager, make sure you use a 32-bit version of the tool that can be found in C:\Windows\SysWOW64\taskmgr.exe.


  2. Copy the resulting snapshot to the computer with installed dotMemory and open it using the Import Dump command.

  3. Analyze the snapshot.

Last modified: 04 August 2020