Oh, Did You Want a Timeout?

Back in February I mentioned that I was reconfiguring my IIS 6 web servers to shutdown the App Pools after 2 hours of inactivity. That seemed a much better option than the brute force iisreset that I’d been scheduling as a nightly event.

Turns out I wasn’t quite done yet. Here’s a snip of a conversation I had earlier today with my CTO, Hans.

“Ya know, I wish I had some better tools to see how many active users we have across all the sites at a given moment,” I said. “That would be helpful when I want to sneak in a quick change during the day.”

“Well what do you currently do to check?” he asked.

“I just pop open the latest IIS log file, jump to the bottom and see if the most recent entries are from my once-a-minute WhatsUp Gold site monitoring. If the last few entries are from WhatsUp then I know we’ve been idle that many minutes.”

He nodded and we moved onto another issue which resolved around some memory related issues.

I commented, “It seems like this main w3p process never shrinks. It just keeps growing its memory usage. How weird. Come to think of it, I’ve never seen a Windows Event about it shutting down or spinning back up…”

Hans just gave me the look and said, “Didn’t you mention your monitoring process hits that site every minute?”

#facepalm#

“oh yeah… I guess it’ll never hit that 2 hour timeout, huh?” Don’t laugh… If you poll the site every minute don’t expect it to ever go idle!

Today I spent some time fixing that. I’m not sure what the best practices are but I have an approach that seems reasonable.

First, I created a new site with just one page (ping.html). Next, I created a new App Pool called monitoring just like the Default. But instead of a timeout I configured it to restart itself at 1:00 AM nightly. Then I converted that new site to an IIS application using that new App Pool.

I changed the WhatsUp monitor to use a custom HTTP Content monitor pointed at the new site. Now it tests for content from the ping.html page instead of just seeing if something responds on port 80 so this is probably even a bit better than it was before.

This brought up another small issue though.

Wait! How do I know which w3p process ties to which App Pool?

Now I have more App Pools all running as the same user. How can I quickly tell which process goes to which pool? Easy!

This picture lays it out:

On the IIS server bring up a command prompt, navigate to the system32 directory and run:

cscript iisapp.vbs

The output lists the process ID (PID) and name for each w3p.exe process. Problem solved.

Possibly Related posts:

1. IIS: No Monitoring Hits in the Logs
2. Fun With WhatsUp and PsService.exe
3. My Web App Isn’t a Spammer
4. A Quick Look at Log Parser