IIS 7.0 : Managing Worker Processes and Requests

The worker process is the heart and soul of Web applications in IIS 7.0. The worker process runs in W3WP.exe and is responsible for processing application requests. In IIS 6.0, worker processes are managed by the World Wide Web Publishing Service service, but in the revamped core engine of IIS 7.0, the WAS owns worker processes.

In IIS 6.0, querying worker process information such as the Process ID (PID) of currently running worker processes and its associated application pool can be done only via the command line script Iisapp.vbs. It is also not possible in IIS 6.0 to peek inside a worker process to look at current request status. Nevertheless, if you are familiar with Event Tracing for Windows (ETW), you can use IIS components as providers to send trace data and events to ETW so that you can look at the request processing details inside a worker process. Although ETW is a powerful tool for request-based tracing, it is not easy to implement, it has no user interface, and it is not really part of the IIS core architecture.

In IIS 7.0, managing worker processes has never been easier and can be done through both IIS Manager and through Appcmd. Thanks to the new core architecture, a request-based tracing feature is now built into IIS 7.0. You can now easily query current requests inside a particular worker process with a few mouse clicks in IIS Manager. Alternatively, you can simply use Appcmd to query the run-time status. Available details include the HTTP verb of the particular request, requested resource name, the processing state of the request, and the module that is currently processing the request.

Monitoring Worker Processes and Requests

Monitoring worker processes gives you a good picture about overall Web server resource usage. You can also use the information to stop a bad worker process that constantly uses all CPU resources or to shut down a bad application pool in which worker processes have long-running requests. To use IIS Manager to query current worker processes and request status, click the IIS computer node in the Connections pane and then double-click Worker Processes in the Features View pane. The Worker Processes page is shown in Figure 1.

Figure 1. Querying current worker processes by using IIS Manager.

To see a list of currently running worker processes, select a worker process in the grid view and click View Current Requests in the Actions pane. Alternatively, right-click a worker process and select View Current Requests. The Requests page is shown in Figure 2.

Use the following Appcmd syntax to display a list of worker processes.

appcmd list wp PID /apppool.name:string

Figure 2. Viewing current requests by using IIS Manager.

The commonly used parameters are listed in Table 1.

Table 1. Syntax for Appcmd to List Worker Processes

Parameter	Description
PID	The process ID for the worker process to list. If omitted, lists all worker processes.
apppool.name	The application pool name for which to show the worker processes.

You can then use the following Appcmd syntax to display a list of currently executing requests.

appcmd list request RequestId /apppool.name:string
/elapsed:integer /site.name:string /wp.name:integer

The commonly used parameters are listed in Table 2.

Table 2. Syntax for Appcmd to List Executing Requests

Parameter	Description
RequestId	The unique identifier of the request, if known. If omitted, lists all requests.
apppool.name	The application pool name to filter by.
elapsed	The amount of processing time in milliseconds to filter by.
site.name	The name of the Web site to filter by. Alternatively, specify a Web site ID via /site.id.
wp.name	The integer represents the process ID of a particular worker process to filter by.

When using Appcmd to query worker process information, the output is not as comprehensive as the list of worker processes in IIS Manager. Appcmd displays only the process ID and the application pool name that the worker process is serving. To list all worker processes in an IIS 7.0 server, use the following command.

appcmd list wp

If any Web applications are running, the preceding command will list the currently running worker processes. For example, the following shows three worker processes are running, each serving a different application pool.

WP "1120" (applicationPool:DefaultAppPool)
WP "3918" (applicationPool:MyAppPool)
WP "3320" (applicationPool:Fabrikam Stock)

Note

The Runtime Status and Control Data and Objects (RSCA) inside the IIS Web server core engine provide run-time data for worker processes.

To query the worker process details for a particular application pool, use the following command.

appcmd list wp /apppool.name:"DefaultAppPool"

In a Web garden setup where more than one worker process is serving the same application pool, you might see the following output, because three different worker processes are serving the DefaultAppPool application pool.

WP "1951" (applicationPool:DefaultAppPool)
WP "3593" (applicationPool:DefaultAppPool)
WP "3039" (applicationPool:DefaultAppPool)

To list all worker processes belonging to a Web site, you would first list all applications belonging to the Web site and then redirect the results to another query. For example, the following command lists worker processes belonging to Contoso Corp.

appcmd list app /site.name:"Contoso Corp" /xml |
appcmd list wp /in

Assuming two running application pools (DefaultAppPool and MyAppPool) are currently assigned to Contoso Corp.’s applications, the output lists two worker processes together with their details.

WP "1120" (applicationPool:DefaultAppPool)
WP "3918" (applicationPool:MyAppPool)

To find out the Web applications or application pools in which a particular worker process is serving, use the following command.

appcmd list wp "1120" /xml | appcmd list app /in

As shown in the preceding code, the first part of the command lists, in XML format, the worker process details including the application pool name. Sample output for this intermediate step is shown here.

<?xml version="1.0" encoding="UTF-8"?>
<appcmd>
    <WP WP.NAME="1120" APPPOOL.NAME="DefaultAppPool" />
</appcmd>

The XML output is then piped as input to the second part of the command, which lists all applications belonging to the application pool. The following shows the final output of the previous full command when root applications of both Contoso Corp. and Fabrikam HR are running in the DefaultAppPool application pool.

APP "Contoso Corp/" (applicationPool:DefaultAppPool)
APP "Fabrikam HR/" (applicationPool:DefaultAppPool)

To peek inside a worker process and look at currently executing requests, you can use the LIST verb and query against a REQUEST object via Appcmd. For example, the using the following syntax displays all currently executing requests on an IIS 7.0 Web server.

appcmd list request

The resulting output, shown in the following syntax, indicates that IIS is currently processing three ASP requests.

REQUEST "f80000008000000e" (url:GET /profile.asp, time:330 msec,
client:10.10.29.12, stage:ExecuteRequestHandler, module:IsapiModule)
REQUEST "f80000008000000f" (url:POST /loginform.asp, time:123 msec,
client:10.11.3.99, stage:ExecuteRequestHandler, module:IsapiModule)
REQUEST "f800000080000010" (url:GET /account.asp, time:200 msec,
client:10.10.29.88, stage:ExecuteRequestHandler, module:IsapiModule)

You can use the /text:* parameter to display all of the returned requests’ attributes, which will contain more useful information than is displayed in the friendly view shown previously.

To list current requests for a particular application pool, use the following.

appcmd list request /apppool.name:"DefaultAppPool"

Alternatively, to display current requests in terms of processing time for the Contoso Corp. Web site with processing time longer than 60 seconds, use the following.

appcmd list request /elapsed:"$>60000" /site.name:"Contoso Corp"

Querying a REQUEST object gives you real-time information about current processing requests, and it can help to identify long-running queries to assist in application troubleshooting. For example, the following command lists the relevant worker processes of all application pools with long-running requests (requests for which processing took more than 60 seconds) and recycles the application pools.

appcmd list request /time:"$>60000"
/xml | appcmd list apppool /in /xml | appcmd recycle apppool /in

Take note of the previous syntax. Although it increases the application availability by recycling the application pool, existing requests and session details are lost during the recycling event. To avoid session variable loss, we recommend that you use out-of-process session management for your Web application. Although this request-based tracing via the REQUEST object gives you real-time information, it does not give you complete event information inside the request processing. To further troubleshoot the bad request, enable the Failed Request Tracing Rules feature so that you can capture detailed event notification inside the processing pipeline.