IIS Discussion Digest: Edition 1
Many Microsoft folks use an internal alias to discuss their IIS issues. Each week plenty of interesting topics come up. I will try to pick the most interesting topics and blog them regularly. I was a bit late this week, but nonetheless here is Edition Numero One:
From: MF
Subject: RE: About HTTP Compression Hi All,
I remember not long ago there was a thread about what would be the minimum size of an output in order to take any advantage of having compression enabled. Can somebody kindly forward that thread to me? Or let me know what was the conclusion on that?
Tnks,
M.
From: JJ
Subject: RE: About HTTP Compression
Well, the simplistic answer is: if it is less than 2.8k compression doesn’t help. Why 2.8k? Because default packet size is 1.4k with a minimum packets per send of 2. So if you try to optimize for less than 2.8 k, you aren’t really doing anything because you aren’t changing the number of packets – which is what drives round trips.
Beyond that statement things get a bit confusing, because you never know how many packets the server is going to send (thanks to NT’s TCP implementation and scalable windows sizes, etc).
From: TK
Subject: IIS 6 Queuing from HTTP.SYS
Delivering some IIS training at present, and had a couple of questions I'm hoping to get some feedback on around Recycling and HTTP.SYS Queuing:
- When recycling a healthy process, is the terminating process able to send any outstanding responses after the new worker process is established? Or is the point at which the new process is registered the point at which the old HTTP.SYS response queue is invalidated? I suspect it's alive for the lifetime of the process, but I'm still reading the docs.
- When recycling a hung application pool, does the new worker process inherit the requests currently in the HTTP.SYS queue for that namespace (assuming the app pool hasn't been picking requests up from the kernel queue for a while), or does the new w3wp only pull new requests from after it starts up?
Thanks!
From: AK
Subject: RE: IIS 6 Queuing from HTTP.SYS
1) WAS recycling works be creating a new Worker Process including its queue and http.sys routing new requests to that queue. The "old" WP is left for draining its queue (unless a timeout is reached… in that case WAS terminates the lingering WP).
2) The above is called “overlapped” recycling. You can (but shouldn’t IMHO) configure non-overlapped recycling. In that case the old WP termination is waited for before a new Worker Process is spun up. I don’t know by heart who owns the queuing of the requests coming in during the time window where the old WP is starting shutdown and the new didn’t yet start.
I hope this helps.
ciao,
A.
From: TD
Subject: RE: IIS 6 Queuing from HTTP.SYS
2) Regarding "who is queuing requests coming in during the time window where the old WP is starting shutdown":
It's HTTP.SYS. When IIS starts (WAS in IIS7 or W3SVC in IIS6) it reads configuration and configures HTTP.SYS. HTTP.SYS creates a request queue and starts listening on the network for requests. No worker processes are running. HTTP.SYS asks WAS/W3SVC to start a worker process when the first request arrives. Once the worker process is running it picks up requests from the HTTP.SYS request queue. Requests in the request queue don't get lost if the worker process is recycled or simply crashes. They simply sit in the HTTP.SYS request queue and wait until a new worker process picks them up.
T.
From: AT
Subject: RE: IIS 6 Queuing from HTTP.SYS
Above is true unless the request is already dispatched to a worker process and the Worker Process was in the middle of sending the response when it crashed. Otherwise associated connection will be aborted. As it is not possible to recover after the Worker Process started sending the response. This is also one of the reasons why draining is necessary as indicated by A. above.