Re: ASP .NET poor performance. Memory going unused??
From: Jerry Pisk (jerryiii_at_hotmail.com)
Date: Thu, 26 Feb 2004 11:51:36 -0800
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.
"Gabriel" <firstname.lastname@example.org> wrote in message
> 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
> > way too many. The more threads you have the more CPU time you waste
> > switching between those threads (take a look at System\Context
> > 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
> > 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
> 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
> GET http://172.18.65.164/incs/images/imagenCabecera.gif HTTP/1.1 (4141
> 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"
> <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"
> responseDeadlockInterval="00:03:00" maxWorkerThreads="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,