Re: Diagnosing horrible performance on Server 2003 Installation

>I'm running a medium-sized website hosted on a virtual server running
>Windows Server 2003 Web Edition.
>
>In the past few months, performance *really* gone downhill. At first I
>blamed this on certain embedded ASP code (not all affected pages used
>it, but I suspected it could still be hurting them if it was inflating
>memory usage). But performance is still horrible after a fresh reboot
>when memory usage is low (it typically increases until levelling out
>at about 270-330MB). And turning ASP processing off on those pages
>doesn't help much either.
>
>Where should I start when trying to determine what the problem is?
>
>Is it possible that our host has started trying to squeeze too many
>virtual servers onto one machine? Are we to blame? (The size of the
>website has grown steadily and significantly, but traffic hasn't). Is
>circa 300MB reasonable usage for w3wp? Is the MS Malicious Software
>Tool sufficient for standard web security use?
>
>Would appreciate any feedback. Thanks!
>
>- MM

Just a hunch but are you using Hyperthreading?

- Thee Chicago Wolf [MVP]

>Hyperthreading? As far as I'm aware, no. The processor is apparently
>an AMD Opteron 270 (2GHz); I assume this is the processor on the
>"real" machine running the virtual machine.
>
>-MM

Ok then, already running SP2? Not sure if Web Edition has an SP2 for
it though.

- Thee Chicago Wolf [MVP]

>Service Pack 2? No; having checked, it's running Service Pack 1; would
>this make any difference?
>
>To be honest, I think it's mostly fixed. There were a couple of issues
>I found (after spending quite a while on it). The first was that a
>sidebar menu that was dynamically generated (but doesn't change *that*
>often) was being reloaded on every page- we fixed this by setting the
>"EXPIRES" HTTP header setting.
>
>The second was that a Perl-based redirect page that a large proportion
>of links on the site go through was taking the opportunity to clean up
>old files *every* time it was run. It wasn't needed anything like that
>often, so we put a rand() in that reduced it to approx. 1 in 40 times.
>(The slowdown was due to it reading the directory listing, which- due
>to us having tens of thousands of files in that directory- *way* more
>than the system was probably meant for- created a noticeable delay).
>
>The feedback was still appreciated though. Is there a systematic
>method that IIS users normally go through to diagnose this sort of
>thing, or is it really a case-by-case diagnosis?
>
>- MM

Usually case by case basis but glad you got it squared away.

- Thee Chicago Wolf [MVP]