Working with Applications, Virtual Directories, and Application Pools
Appcmd can be an effective way to create and
configure many of the key Web server objects, including Web sites,
applications, virtual directories, and application pools. The Appcmd Site, App, Vdir, and Apppool
objects provide a convenient mechanism for managing these objects, even
though you can perform most of the tasks that these objects expose by
using the Config object to directly edit configuration files.
The Site
object provides a convenient way to enumerate Web sites, as well as to
create new Web sites and set configurations on existing Web site
definitions. For example, you create a Web site in a single step by
using the Add Site command.
ppcmd add site /name:MySite /bindings:http/*:81: /physicalPath:c:\mysite
This command creates a new Web site, listening
on port 81, and automatically creates a root application and a root
virtual directory pointing to C:\mysite. You can also create the Web
site separately by omitting the physicalPath parameter and then create applications and virtual directories for the Web site by using the Add App and Add Vdir commands respectively.
You can use the List Sites
object to list the Web sites on the server or find specific Web sites
by attributes or URL. For example, to determine which Web site is
configured to serve requests to http://localhost:83, you can use the following syntax.
appcmd list sites http://localhost:83
To find all sites that are currently stopped, you can use the following syntax.
appcmd list sites /state:Stopped
You can also manually start and stop Web sites by using the Start Site and Stop Site commands.
Similar to Web sites,
you can also create, list, and manipulate applications, virtual
directories, and application pools.
Working with Web Server Modules
The Module
object in Appcmd provides convenient methods for installing, enabling,
and managing Web server modules. Again, you can perform the majority of
these tasks by using the Config object to directly edit configuration files.
For example, you can install native modules by using the Install Module command.
appcmd install module /name:MyNativeModule /image:c:\mymodule.dll
You can use the same command to add new managed modules.
appcmd add module /name:MyManagedModules /type:MyModules.MyManagedModule
You can also manage which modules are enabled on your Web server or application by adding or deleting modules.
Inspecting Running Worker Processes and Requests
Viewing
and changing configuration data is not the only thing that you can do
with Appcmd. You can also inspect the run-time state of the Web server
by listing the currently executing worker processes and even requests.
Listing Running IIS Worker Processes
You can use the List Wp command to list all currently running IIS worker processes. This command uses the following syntax.
appcmd list wp [pid] [/apppool.name:string] [/wp.name:string]
The List Wp
command supports the use of the Process ID (PID) as an identifier to
locate the specified IIS worker process. Additionally, you can specify
the application pool name by using the /apppool.name parameter to list IIS worker processes belonging to a specific application pool.
For example, to list all IIS worker processes that are currently running, you can use the following syntax.
appcmd list wp
The output of this command includes the PID of each IIS worker process, as well as the application pool to which it belongs.
WP "3284" (applicationPool:DefaultAppPool)
Listing Currently Executing Requests
In addition to viewing the currently
running worker processes, you can also look deeper into the Web server
operation by listing currently executing requests. This can give you a
snapshot of current system activity, as well as show which requests have
been executing for a long time (thus possibly indicating a problem).
You can list the currently executing requests by using the List Request command. For example, to list all currently executing requests on the server, you can use the following syntax.
appcmd list requests
The output contains all requests that were executing in all IIS worker processes at the moment of query.
REQUEST "fd00000180000004" (url:GET /wait.aspx?sleep=10000, time:4072 msec,
client:localhost, stage:ExecuteRequestHandler,
module:ManagedPipelineHandler)
As
you can tell, each displayed request object contains quite a bit of
information about the currently executing request, including:
-
The request URL and verb.
-
The time that the request has spent executing.
-
The client issuing the request.
-
The pipeline stage that the request is currently in, and the module that is currently executing.
You can use the time information—as
well as the current pipeline stage and module data—to effectively
troubleshoot request hangs and performance degradation problems, by
pinpointing the exact URL and in some cases even the module that is
causing the slowdown.
In addition to listing all requests on the
server, which can be an expensive operation and may give too much
information to be useful in a lot of scenarios, you can use a variety of
filters to list only the relevant requests. To see how to do this,
let’s look at the detailed syntax of the List Requests command.
appcmd list requests [identifier] [/site.name:string] [/wp.name:string]
[/apppool.name:string] [/elapsed:uint] [/url:string] [/verb:string]
[ClientIp:string] [/stage:string] [/module:string]
This command supports the parameters listed in Table 1.
Table 1. Parameters for the List Requests Command
|
Parameter |
Description |
|---|
|
identifier |
The request identifier to look up a specific
request multiple times. The request identifier is a randomly generated
string similar to "fd00000180000004" that is shown when requests are
displayed in Appcmd. |
|
site.name |
The site name for which to display currently running requests. |
|
wp.name |
The IIS worker process PID for which to display
currently running requests. This improves the efficiency of the query
because only the specified IIS worker process is polled. |
|
apppool.name |
The application pool name for which to display
currently running requests. This improves the efficiency of the query
because only the IIS worker processes for the specified application pool
are polled. |
|
elapsed |
The minimum elapsed time in milliseconds for
requests to show. Requests that have taken less time to execute are not
returned. This may increase the efficiency of the query by returning
fewer requests. Using the elapsed attribute is an effective way to determine hung requests. |
|
url |
The URL of the request. You can specify the
exact URL or wildcard expressions on URLs to show requests only to
specific URLs (note that the URL may contain the query string as well). |
|
clientip |
The IP of the requesting client. This can be in both IPv4 and IPv6 format depending on the client’s connection. |
|
stage |
The request processing stage. Use to show
only requests that are currently executing in the specified request
processing stage. |
|
module |
The name of the module. Use to show only the requests that are being processed by the specified module. |
