ASP .NET poor performance. Memory going unused??

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Gabriel - 25 Feb 2004 19:30 GMT

I'm running system tests against a Windows 2003 server installed in a
Xeon with two processors (2.5GHz approx. each) and 1 Gb of RAM (Not
running web garden though). The test basically consists on a simple
navigation which loads one page, which generates six http requests.
I'm running the same test on three differente scenarios with 1, 150
and 300 concurrent users. I'm using OpenSTA and the Windows
performance monitor to carry out and monitor the results.

I'm getting a very poor response times average, for such a simple
test. Checking the performance monitor counters noticed the following:
The %processor time peak varies depending on the scenario (6, 54 and
66 respectively) whereas the System Threads and available memory
counters don't. The threads counter is 560 (490-500 before running the
test) and the minimum available memory is around 616Mb for all the
tests. Shouldn't be the number of threads higher and the minimum
amount of free memory at a time quite lower? This means to me the iis
is not fully using the system resources at all. Is this assumption
correct?

I was checking some documentation and was wondering whether this could
be a problem with the thread pools, memory and queues configuration in
the machine.config file. More exaclty, something to do with the
ProcessModel and httpRuntime attributes. I'll try messing with these
values to see if I get different results, though I'm quite blind on
this and the docs I've read are quite confusing and ambigous.

Any help on this would be very much appreciated.

Cheers and thanks in advance,

Gabriel.

Reply to this Message

Jerry Pisk - 25 Feb 2004 21:29 GMT

You shouldn't see more threads, even those 500+ you're seeing is probably
way too many. The more threads you have the more CPU time you waste
switching between those threads (take a look at System\Context Switches/sec
performance counter, it should be in the low hundreds).

The problem could be pretty much anything, you're definitely not giving us
any information as to what the issue might be. I suggest you start reading:
http://msdn.microsoft.com/library/en-us/dnaspp/html/monitor_perf.asp and
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/serverop/par
t2/sopch05.asp
(if you don't want to read the whole thing take a look at Table 5.8).

And of course posting the code would help as well, the problem might be as
simple as inefficient code.

Jerry

> I'm running system tests against a Windows 2003 server installed in a
> Xeon with two processors (2.5GHz approx. each) and 1 Gb of RAM (Not
[quoted text clipped - 27 lines]
>
> Gabriel.

Reply to this Message

Gabriel - 26 Feb 2004 12:27 GMT

First of all, I must say I'm quite a newbie on Windows systems, so
excuse my ignorance as I really have no experience at all configuring
windows server systems.

> You shouldn't see more threads, even those 500+ you're seeing is probably
> way too many. The more threads you have the more CPU time you waste
> switching between those threads (take a look at System\Context Switches/sec
> performance counter, it should be in the low hundreds).

Before running the test, the threads counter average is already 507
and there is nothing but the performance monitor running on the
server. I added the counter you mentioned. Before running any test its
average value is 720. I ran the same test with only 20 concurrent
users. The threads average only went up to 508 but the switches/sec
average went up to 1315. You said this value should be in the low
hundreds, so I must understand we are doing something wrong at a
configuration level. The question is whether is a Windows 2003 server
or an iis6 config problem.

> The problem could be pretty much anything, you're definitely not giving us
> any information as to what the issue might be.

The test consits simply on a user clicking on a url requesting a aspx,
which is the starting point of an application, a login page exactly.
There is nothing else involved in this test. The only code is executed
is the Page_load() method:

private void Page_Load(object sender, System.EventArgs e)
{
if (!IsPostBack)
    {
        Cabecera.Titulo    = "Acceso";
    }
}

As I said before, this generates six http requests, which are:

GET http://172.18.65.164/incs/images/logoCabecera.gif HTTP/1.1 (2795
bytes)
GET http://172.18.65.164/incs/css/DOTNET.CSS HTTP/1.1 (10357 bytes)
GET http://172.18.65.164/incs/js/AqCtrlBarraInfo.js HTTP/1.1 (1510
bytes)
GET http://172.18.65.164/incs/images/imagenCabecera.gif HTTP/1.1 (4141
bytes)
GET http://172.18.65.164/incs/images/vacio.gif HTTP/1.1 (1056 bytes)
GET http://172.18.65.164/Net.Ap.AdminSeguridad/gestionseguridad.aspx
HTTP/1.1 (4122 bytes)

When running this, as you can see pretty straighforward, test with 300
concurrent users, I'm getting a response time (to the six requests)
average value of 1.892 seconds (0.7 min and 6.4 max value). I consider
these pretty high response values. For the users whose responses take
more than 6 seconds, it seems like the iis is queing their http
requests. I tried a more complicated test, adding one more page
navigation and I can see in the perfomance monitor how when there are
lots of concurrent requests waiting to be answered the system memory
usage doesn't significantly grow.

Well, my question basically was whether or not it is a normal thing
that the System available memory NEVER goes down from 600Mb. The fact
the iis is queing requests when there is still a huge amount of free
memory makes me think that we are doing something wrong configuring
the iis. Having a look at the machine.config file, I can see there are
a number of attributes (httpRuntime and processModel sections) that
have to do with threads, queues and memory configuration. The values
we have set are:

<httpRuntime executionTimeout="90" maxRequestLength="4096"
useFullyQualifiedRedirectUrl="false" minFreeThreads="8"
minLocalRequestFreeThreads="4" appRequestQueueLimit="100"
enableVersionHeader="true"/>

<processModel enable="true" timeout="Infinite" idleTimeout="Infinite"
shutdownTimeout="0:00:05" requestLimit="Infinite"
requestQueueLimit="5000" restartQueueLimit="10" memoryLimit="60"
webGarden="false" cpuMask="0xffffffff" userName="machine"
password="AutoGenerate" logLevel="Errors"
clientConnectedCheck="0:00:05" comAuthenticationLevel="Connect"
comImpersonationLevel="Impersonate"
responseDeadlockInterval="00:03:00" maxWorkerThreads="20"
maxIoThreads="20"/>

I tried changing the appRequestQueueLimit to 500 but had no effect. I
don't know whether any of these values might be constraining the way
the iis is using resources.

I can't think of anything else.

Thanks again,

Gabriel.

Reply to this Message

Jerry Pisk - 26 Feb 2004 19:51 GMT

You ask a lot of questions so I'll try to answer them separately:

1315 context switches per second is a lot, especially on Windows 2003 server
(mine runs about 150 when idle and several hundreds when under load). The
problem here is that identifying the problem is very difficult, most of the
times it's caused by lock contention - for example you'd request a lock for
a time period longer then very short in your login page, effectively
serializing those requests. Or you could be using single threaded COM
objects, again, effectively serializing your requests. But even though this
shows there might be a problem here it's the least of our worries now.

As for the thread counts - you're probably talking about the number of
threads in the system. If that is the case then the numbers you're seeing
are perfectly normal. Try watching thread count for your worker process
(wpw3, the one that runs your application pool) instead of the whole system.
However, from your numbers this doesn't seem to be a problem either.

Serializing requests - IIS (and Asp.Net) will not process than a certain
number of requests simultaneously. That's perfectly normal and will give you
better performance then creating a thread for each request. But a minimum
request time of 0.7 seconds is terrible, especially for a page that does
nothing. I have pages that execute couple database queries and dump the
results that execute a lot faster than that. Some of it might be hardware
related but anything capable of running Windows 2003 server should be able
to serve a fairly static page faster than that. Could you post the whole
page here? Along with your global.aspx if you're using it?

Now on to the memory usage - since your pages are pretty static and do not
create a lot of data in the memory the memory usage should be fairly static.
You don't need to worry about having too much available memory. But I
suggest you watch Memory\Virtual Bytes counter for your worker process
(w3wp, the one running your application pool), if that number is 1.4 or 2.4
GB (2.4 if you boot your server with /3GB switch, 1.4 otherwise) you most
likely have a memory leak in your application. On the other hand - if your
memory usage was this high I doubt the available memory would be more than
few megabytes. But it's still worth a try.

To sum it up - it seems to me that it's either inadequate hardware or
inefficient code. Having too much available memory isn't hurting anything.

Jerry

> First of all, I must say I'm quite a newbie on Windows systems, so
> excuse my ignorance as I really have no experience at all configuring
[quoted text clipped - 87 lines]
>
> Gabriel.

Reply to this Message

ASP .NET poor performance. Memory going unused??

Free Magazines