Re: IIS6 slow response for requests

I would stop the un-used app pool, this will free up memory. If they are
not going to be used, remove them will prevent them from starting up again.
I would isolate the troublemaker application pools and focus your efforts on
troubleshooting that. Move the bad app(les) off the server, if that is an
option.

Other things to check is memory perf counters, make sure your paging file is
approximately 1 1/2 times the physical ram. Those are small things that can
help with perf.

Steve Schofield
Windows Server MVP - IIS
http://weblogs.asp.net/steveschofield

"Horatiu Popovici" wrote in message
news:%23bI2CUS8HHA.3900@TK2MSFTNGP02.phx.gbl...
> Hello
> My problem is still there.
> We grouped some of the 150 web sites that used 90 Application pools into
> common pools and we stopped the one that where before.
>
> What is better? To stop unused application pools or to remove them at all?
>
> Still we get a pretty slow response from the main application we where
> trying to improve. Request for a normal aspx(without DB inquire) page
> take for single session 6 sec. We did tried to deploy the same source
> code on a different server, and on that the application was very fast.
>
> I am running out of option right now. Any thoughts?
> I suspect some memory leaks in the code too, but it seems that
> DebugDiags fails to load the MemLeak monitor for that server(image
> attached)
>
> Any ideas is/are welcomed.
>
> Best regards
> Horatiu Popovici
>

Re: IIS6 slow response for requests

On Sep 7, 7:41 pm, "Steve Schofield" wrote:
> I would stop the un-used app pool, this will free up memory. If they are
> not going to be used, remove them will prevent them from starting up again.
> I would isolate the troublemaker application pools and focus your efforts on
> troubleshooting that. Move the bad app(les) off the server, if that is an
> option.
>
> Other things to check is memory perf counters, make sure your paging file is
> approximately 1 1/2 times the physical ram. Those are small things that can
> help with perf.
>
> Steve Schofield
> Windows Server MVP - IIShttp://weblogs.asp.net/steveschofield
>
> "Horatiu Popovici" wrote in message
>
> news:%23bI2CUS8HHA.3900@TK2MSFTNGP02.phx.gbl...
>
>
>
> > Hello
> > My problem is still there.
> > We grouped some of the 150 web sites that used 90 Application pools into
> > common pools and we stopped the one that where before.
>
> > What is better? To stop unused application pools or to remove them at all?
>
> > Still we get a pretty slow response from the main application we where
> > trying to improve. Request for a normal aspx(without DB inquire) page
> > take for single session 6 sec. We did tried to deploy the same source
> > code on a different server, and on that the application was very fast.
>
> > I am running out of option right now. Any thoughts?
> > I suspect some memory leaks in the code too, but it seems that
> > DebugDiags fails to load the MemLeak monitor for that server(image
> > attached)
>
> > Any ideas is/are welcomed.
>
> > Best regards
> > Horatiu Popovici- Hide quoted text -
>
> - Show quoted text -


Can you clarify WHAT exactly are you trying to improve?

Why were you using 90 application pools before, and why did you move
them all to a single application pool?

Why do you suspect there is a memory leak? Do you have any conclusive
evidence pointing to a memory leak?

It *sounds* like you are trying to improve the performance of the main
application from 6 seconds. You said that it was "fast" on a different
server, but how comparable are the two servers? Are they the exact
same physical hardware (CPU, RAM, HDD, NetworkCard) and software (OS,
Application Framework(s))?

For example, if your slow server is a Pentium 3 with 128MB RAM,
clearly no amount of software changes are going to help its
performance -- it is physically bottlenecked.

Whenever you want to improve performance, you ALWAYS start by
identifying the bottleneck to performance. You don't just "guess"
about a memory leak or theorize by running the same software on a
different server.

Track CPU utilization, HDD queueing, Network Bandwidth, and RAM
consumption on the server that takes 6 seconds for a single session.
And I hope that your performance measurement of 6 seconds is an
average response time over something like 1000 requests over 30
seconds and not just a single request because we all know about .Net's
slow first startup for that first ASPX request as IIS spins up a new
worker process and CLR pre-load/pre-jit everything and that takes
time.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//