ASP .Net Workers Test

This reports statistics pertaining to the performance of the worker process of the ASP .NET objects in the Voyager user interface.

Target of the test : The ASP .NET objects in the Voyager user interface

Agent deploying the test : An internal agent

Outputs of the test : One set of results for the ASP .NET objects in the Voyager user interface being monitored.

Configurable parameters for the test
Parameter Description

Test Period

How often should the test be executed.


The IP address of the host for which this test is to be configured.


Refers to the port at which the specified host listens to.

Measurements made by the test
Measurement Description Measurement Unit Interpretation

Application restarts

The number of application restarts.


In a perfect world, the application domain will and should survive for the life of the process. Even if a single restart occurs, it is a cause for concern because proactive and reactive restarts cause automatic recycling of the worker process. Moreover, restarts warrant recreation of the application domain and recompilation of the pages, both of which consume a lot of time. To investigate the reasons for a restart, check the values set in the processModel configuration.

Applications running

The number of applications currently running.



Requests current

The number of requests currently handled by the ASP.NET ISAPI. This includes those that are queued , executing, or waiting to be written to the client.



Request execution time

The number of seconds taken to execute the last request.


In version 1.0 of the framework, the execution time begins when the worker process receives the request, and stop when the ASP.NET ISAPI sends HSE_REQ_DONE_WITH_SESSION to IIS. In version 1.1 of the framework, execution begins when the HttpContext for the request is created, and stop before the response is sent to IIS. The value of this measure should be stable. Any sudden change from the previous recorded values should be notified.

Requests queued

The number of requests currently queued.


When running on IIS 5.0, there is a queue between inetinfo and aspnet_wp, and there is one queue for each virtual directory. When running on IIS 6.0, there is a queue where requests are posted to the managed ThreadPool from native code, and a queue for each virtual directory. This counter includes requests in all queues. The queue between inetinfo and aspnet_wp is a named pipe through which the request is sent from one process to the other. The number of requests in this queue increases if there is a shortage of available I/O threads in the aspnet_wp process. On IIS 6.0 it increases when there are incoming requests and a shortage of worker threads.

Requests rejected

The number of rejected requests


Requests are rejected when one of the queue limits is exceeded. An excessive value of this measure hence indicates that the worker process is unable to process the requests due to overwhelming load or low memory in the processor.

Requests wait time

The number of seconds that the most recent request spent waiting in the queue, or named pipe that exists between inetinfo and aspnet_wp. This does not include any time spent waiting in the application queues.



Worker processes running

The current number of aspnet_wp worker processes


Every application executing on the .NET server corresponds to a worker process. Sometimes, during active or proactive recycling, a new worker process and the worker process that is being replaced may coexist. Under such circumstances, a single application might have multiple worker processes executing for it. Therefore, if the value of this measure is not the same as that of Applications running, then it calls for closer examination of the reasons behind the occurence.

Worker process restarts

The number of aspnet_wp process restarts in the machine


Process restarts are expensive and undesirable. The values of this metric are dependent upon the process model configuration settings, as well as unforeseen access violations, memory leaks, and deadlocks.