CODEWITHSUNDEEP
asp.netiis
skb
skb

Reputation: 31084

ASP.NET performance under load

I am having problems figuring out why my ASP.NET application cannot sustain a large number of concurrent users. I am running the VS Load Test Tool and I have tons a valuable data, but struggling to sift through it all. I am using a Step user load pattern which increases the number of virtual users gradually until reaching about 500. The tests seem to hum along with no problem until some unhandled exception in the app causes it to crash. Up until the crash, the memory, CPU utilization and all other perf counters I am monitoring stay totally flat. But once the crash happens, I observe the following:

  1. ASP.NET/Requests Current perf counter spikes
  2. ASP.NET/Requests Queued perf counter goes up a tiny bit, but stays less than 10
  3. .NET CLR LocksAndThreads/Current Queue Length spikes

After this, the load test never recovers. (NOTE: I'm not asking for help why the app crashes, that is something else that I am working on separately and will fix, but there could always be a new app crash and I don't want my app to be unrecoverable under load). I can also reproduce this behavior if I just restart IIS in the middle of the load test, or if I start a load test on a freshly restarted IIS instance without letting the number of users gradually build up (just hammer it with 500 users from the get-go).

So my question is, why is it that IIS can't handle a large number of users right when it starts?

Upvotes: 2

Views: 903

Answers (1)

jbl
jbl

Reputation: 15413

AFAIK, upon IIS restarting or App pool recycling, the following will happen :

  • the assemblies will have to be reloaded
  • the pages will get recompiled
  • the SQL connections will be closed

You can :

  • check the recycling section of your app pool advanced settings to see if a recycling may trigger on memory limit, regular time, ...
  • load some assemblies in the GAC
  • check that there is no batch="false" attribute in the compilation element of your web.config
  • raise the min and max pool size in your SQL connection strings (not forgetting session connection strings)
  • check that no time consuming process is taking place upon startup (like some NHibernate dynamic mapping)

Upvotes: 1

Related Questions