We want to deploy a web site on II6.0/7.0 for intranet use only. The web site has a typical three tier architecture. The middle tier is deployed as an application server on the same machine as IIS. The asp.net code running in worker process makes call to application server, which in turn connects to database for data.

We are doing load testing using Load Runner and observed few things. Even for 20 concurrent user testing, IIS is giving 401, 500 and time out errors in a very random manner. The problem is very random. Sometimes the testing for more number of user succeeds without any error but fails for few users. IIS behavior is not predictable.

Server Machine Details (Application Server + IIS)

1) Dual proc quad core 2) 8 GB RAM


  1. Are there any IIS parameters that needs to be tweaked to support max of 250 concurrent users?
  2. Could there be any problem with the asp.net code?
  3. What should be the strategy of resolving the above mentioned problem?
  • 3
    I think this belongs on ServerFault.com Dec 15 '10 at 10:27
  • 1
    Have you tried profiling your site to see where the bottlenecks are for requests to take so long to be processed.
    – Phill
    Dec 15 '10 at 10:32
  • @AgentConundrum: Then click close please.
    – leppie
    Dec 15 '10 at 10:32
  • 1
    I dont believe this should be on serverfault, his application is the issue, not the server.
    – Phill
    Dec 15 '10 at 10:37
  • @leppie: If I had another 110 reputation, I would. Dec 15 '10 at 10:38

If your app is stuggling with 20 concurrent users and its not doing something very intensive like industrial-strength number-crunching, I would be inclined to take a guess that its the code that may be to blame rather than IIS.

My first suggestion is you check the codebase for bad design/logic, optimise database and data access routines and see if that has any effect. You could try using Resharper or similar to assist you in this.


I'm inclined to blame the asp.net code. IIS should serve 250 users without breaking a sweat.

Either way , 1) turn on custom errors to find the exact point in the app where it is failing. 2) attach a debugger and see where you have timeouts or loops that do not return.

I'd approach this as a simple troubleshooting a timeout bug rather than tweaking with configuration issues.

The fact that is not predictable does not point to the IIS either..it probably means the error is dependent on some shared resource or some un-deterministic code paths.


Two words : Server Caching.

Analyze your app and see what can be cached at what level, starting with Asp.Net's Page Output caching and diving into the layers adding caching in each layer as fits. Find your bottlenecks and ask yourself how often that process needs to be called. Is that data unique to each user? If not, then cache it once and use the cached value for subsequent requests. Does the data only change at a certain time? If so, fetch it once and set the cache to expire at that time. I can assure you that this alone will make dramatic improvements in your capacity.

250 concurrent users of application that generates uncached page content dynamically on a single box is a pretty tall order simply due to the constraints of the hardware itself. The pipes are only so big and without caching, you will fill them fast.


Take at look at MSDN blog : Maximize the Number of Concurrent Connections to IIS6


Use the ANTS profiler to find the slowest lines in your code. Also, increase the number of threads permitted, I think in the web.config. Maybe also increase the timeout, and remove functions (such as getdate) and especially table valued functions from your SQL code. If you absolutely need a function in your views for example, use ODBC escape sequences, such as {fn curdate()}, because ODBC functions are canonical functions (indexable), while ordinary SQL server functions are non-deterministic (not indexable).


If you are getting a 500 response and a timeout, that indicates that the webserver is handling the request just fine, but something needed to complete the request is timing out - probably the request that the web server posted to the app server. If the problem was on the web server, you would be more likely to get a connection failure or network timeout error (i.e. no HTTP response at all), rather than a 500 response. I would start by looking at the metrics from the app and db servers. If the usual metrics look good, then look for locking behavior. A DBA should spot this quickly on the db, but in the app server code (custom code, I assume?), you will need to dig deeper.


I'm with the others: something's likely wrong with your application. However, you didn't say whether this app works well on other hardware (is there a developer's machine where this is installed on that you can run Load Runner against?) or not.

Having said that, if you think the server hardware and/or configuration is suspect, you could install Microsoft .NET Pet Shop 4.0 (for .NET 2.0 applications) or perhaps DotNetNuke, an open source .NET Content Management System (CMS) on the same hardware and see how they stack up against Load Runner. If they both fail the tests, then perhaps your hardware is suspect (and I'd put it on another machine to test) or your Load Runner configuration/parameters are not correct and you should be looking there.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy