Relation between HTTP.sys request queue and IIS app pool

1
votes

I read this from < IIS 7.0 resource kit >

HTTP.sys maintains a request queue for each worker process. It sends the HTTP requests to the request queue for the worker process that serves the application pool where the requested application is located. For each application, HTTP.sys maintains the URI namespace routing table with one entry. The routing table data is used to determine which application pool responds to requests from what parts of the namespace. Each request queue corresponds to one application pool. And application pool corresponds to one request queues within HTTP.sys and one or more worker processes.

The bold parts confused me. My understanding is: HTTP.sys matain a request queue for each worker process. An application pool can have one or more worker processes. So an application pool should also corresponds to one or more request queues. Why only one in the bold sentence?

And btw, could anyone give a more clear explanation about the URI namespace routing table? Some examples would be better.

Thanks.

4
iisiis-7
Information here docs.microsoft.com/en-us/windows/desktop/http/process-isolation helped me out. The answer below is correct. - andrewramka

4 Answers

2
votes

To discuss a paragraph in a book, you should give more info.

This paragraph comes from "IIS 7.0 Core Components" section, and the version at Safari Books Online is different from what you pasted,

HTTP.sys maintains a request queue for each worker process. It sends the HTTP requests it receives to the request queue for the worker process that serves the application pool where the requested application is located. For each application, HTTP.sys maintains the URI namespace routing table with one entry. The routing table data is used to determine which application pool responds to requests from what parts of the namespace. Each request queue corresponds to one application pool. An application pool corresponds to one request queue within HTTP.sys and one or more worker processes.

So the last sentence should be understood as,

  • An application pool corresponds to one request queue within http.sys.
  • An application pool corresponds to one or more worker processes.

Thus, your understanding of "HTTP.sys maintains a request queue for each worker process" is not correct. The correct one should be "HTTP.sys maintains a request queue for each application pool". So no matter how many worker processes are there for a single application pool, they only serve requests from a single request queue in http.sys.

"For each application, HTTP.sys maintains the URI namespace routing table with one entry"

I think it should be "for each application pool, HTTP.sys maintains the URI namespace routing table with one entry". This routing table makes it easier to dispatch requests (whose URL is clear) to the pools. Very similar to a hash table.

The table can be constructed from <sites> tag in applicationHost.config, by combining sites, their bindings, applications, and their application pool association. There is no further information from Microsoft on the exact table structure.

1
votes

I am struggling with the same question... but I think the process is as follows:

  1. Request intercepted by HTTP.sys
  2. HTTP.sys makes initial contact with WAS
  3. WAS read the ApplicationHost.config and passes it the WWW service.
  4. WWW service configures HTTP.sys (from this point, the HTTP.sys has set up the corresponding application pool queue I guess)
  5. HTTP.sys checks if an worker process is available, (contacts WAS via WWW) if not, the request is stored in the application queue.

=> if a worker process is available, the request is now forwarded to the correct worker pool

If no worker process is available, the request is stored in the application queue. HTTP.sys will now notify WAS (via the WWW service) that a new request has been added to the queue. The WWW service will ask WAS for a worker process. WAS will spawn one and let WWW know that an app pool has been created. Now WWW can pass the request to the corresponding worker process(by adding it to its queue queue). Then WWW will let HTTP.sys know that a worker process is spawned, so the next request, HTTP.sys can forward the request immmediatly...

I am not completely sure if this is technically all correct, so if anyone could correct/confirm this, that would be great!

0
votes

A listener needs to receive messages. For this, it needs to open a socket (or a pipe handle, or start an MSMQ read, and so on). However, in order to receive the proper messages, it needs to obtain the necessary addressing information from WAS. This is accomplished during listener startup. The protocol's listener adapter calls a function on the WAS listener adapter interface and essentially says, "I am now listening on the net.tcp protocol; please use this set of callback functions I'm handing you to tell me what I need to know." In response, WAS will call back with any configuration it has for applications that are set up to accept messages over the protocol in question. For example, a TCP listener would be informed that there were two applications (*:7777/Foo and *:7777/Bar) configured to use TCP. WAS also assigns to each application a unique listener channel ID used for associating requests with their destination applications. The listener process uses the configuration information provided by WAS to build up a routing table, which it will use to map incoming requests to listener channel IDs as they arrive.

-2
votes

An application pool can have one or more worker processes

This is not correct 1 App Pool = 1 Worker Process