Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top


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 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 code?
  3. What should be the strategy of resolving the above mentioned problem?
share|improve this question

migrated from Dec 16 '10 at 14:51

This question came from our site for pro webmasters.

I think this belongs on – AgentConundrum Dec 15 '10 at 10:27
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
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. – AgentConundrum 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.

share|improve this answer

I'm inclined to blame the 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 probably means the error is dependent on some shared resource or some un-deterministic code paths.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer

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).

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.