1

This could be a network thing at my ISP where my box is colocated...not entirely sure. I wanted to just check here to see if anyone has seen an issue like this that is server related so I can check there as well.

if I go to one of my web sites, I get an "unable to connect" message in firefox. If I F5 two or three times, it comes up, but this is not good for my SEO nor my customers that are trying to hit my sites from the search engines...they wouldn't know to refresh the page.

I've done an iisreset and actually just rebooted the whole box...same problem still exists.

I've checked my event viewer (both application and system logs) and there's nothing out of the ordinary going on there. I can RDP to my box just fine and have no hiccups. A ping /t to one of ips doesn't yield timeouts.

I'm at a loss of what to check next...

Update:

One thing I neglected to mention is that this server has been serving pages since October 2011 with no issues whatsoever. This just started today.

Looks like it is the server and not the network as it's showing the same symptoms when I try to fetch the sites locally.

I'm not entirely sure that it's the app pool being loaded the first time that's causing the problem. Reason being, I can load up a site in firefox, then try it in chrome immediately afterwards, and it won't come up.

It's not on a VM.

1 Answer 1

2

Some theory that might help you develop a plan:

  • IIS 7.5 creates each website as an App Pool (if you create it through the GUI)

  • One App Pool runs in one W3WP.exe

  • W3WP Startup is the most expensive time of an App Pool's life

  • App Pools are (mostly) demand-started - they only start when a request arrives

  • IIS times out (shuts down) idle Application Pools after 20 minutes by default

  • Overlapping recycling is faster than cold startup

  • IIS has a default startup time limit for App Pools of 90 seconds, and they get terminated (and recycled, i.e. started again) if they're not running by that number.

If you're finding your first-request performance is abominable:

  • it could just be that your app does a ton of stuff when it's first run, which would be affected by IO/network/db performance

  • don't let the app pool stop

  • examine the IO happening during app pool startup - ResMon (included in W2008R2 & W7) might give you a good insight into this, particularly on the disk tab where it shows rough bytes/sec rates and IO wait times

  • use Perfmon to track the performance of the site vs IO performance vs W3WP startup times

    • and general performance in terms of CPU/Net/Disk/Mem - if any of them bottleneck app startup, improve them

If the box itself is a shared VM, I'd suggest it's either too shared, or hasn't been scaled appropriately. Perf counters involving wallclock rather than relative-perceived-by-VM-time might be useful in diagnosing that.

5
  • Why the downvote? I admit I know next to nothing about IIS, but this seemed useful.
    – Bigbio2002
    Feb 13, 2012 at 23:16
  • thanks for the information. one thing I neglected to mention is that this server has been serving pages since October 2011 with no issues whatsoever. This just started today. I'm going to try hitting the sites from the machine itself to try and determine if it's network related or the server having issues. If I determine it's the server, I'll try some of these suggestions. Feb 14, 2012 at 0:22
  • looks like it is the server as it's showing the same symptoms when I try to fetch the sites locally. It's not on a VM. I'm not entirely sure that it's the app pool being loaded the first time that's causing the problem. Reason being, I can load up a site in firefox, then try it in chrome immediately afterwards, and it won't come up. How can I check what the time limit is set to for my app pools to expire? Also, while I appreciate the theoretical overview, do you have any suggestions for plans of actions to try and resolve this? Feb 14, 2012 at 0:38
  • The suggestions were in the bottom half, but I'll add to that taking a memory dump of a w3wp while it's in its first-request state, and feeding that into DebugDiag 1.2 for a quick best-guess about what's causing it to take so long. Could be something as simple as generatepublisherevidence, or more complicated. You might want to update the question with the new known information so that others can offer more accurate suggestions (I'll help).
    – TristanK
    Feb 14, 2012 at 6:21
  • + App Pool idle timeout is configurable through Advanced app pool properties.
    – TristanK
    Feb 14, 2012 at 6:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .