我们只想在II6.0 / 7.0上部署一个网站，仅供内联网使用。 该网站有一个典型的三层架构。 中间层作为应用程序服务器部署在与IIS相同的机器上。 工作进程中运行的asp.net代码会调用应用程序服务器，应用程序服务器又会连接到数据库以获取数据。
我们正在使用Load Runner进行负载testing，并观察了几件事情。 即使对于20个并发用户testing，IIS也会以非常随机的方式给出401,500和超时错误。 问题是非常随机的。 有时对更多用户的testing成功没有任何错误，但对于less数用户失败。 IIS的行为是不可预测的。
1）双处理器四核2）8 GB RAM
如果你的应用程序与20个并发用户混合在一起，并且没有像工业强度的数字处理那样做非常密集的事情，我会倾向于猜测它的代码可能是责备而不是IIS。
我的第一个build议是检查糟糕的devise/逻辑的代码库，优化数据库和数据访问例程，看看是否有任何影响。 你可以尝试使用Resharper或类似的协助你。
我倾向于责怪asp.net代码。 IIS应该为250位用户服务，而不会冒出任何问题。
无论哪种方式，1）打开自定义错误，以find失败的应用程序中的确切点。 2）附加一个debugging器，看看你有超时或循环不返回。
我会把它作为一个简单的故障排除超时错误，而不是调整configuration问题。
不可预测的事实并不指向IIS。这可能意味着错误取决于一些共享资源或一些不确定的代码path。
两个字：服务器caching。
分析你的应用程序，看看什么可以caching在什么级别，从Asp.Net的页面输出caching开始，并潜入到每层中添加caching的图层。 找出你的瓶颈，并问问你自己多久需要调用这个过程。 这些数据对每个用户都是唯一的吗？ 如果没有，则caching一次，并使用caching的值进行后续请求。 数据只在某个时间变化吗？ 如果是这样，请取一次，并将caching设置为过期。 我可以向你保证，只有这一点才能使你的能力有显着的提高。
250个并发用户的应用程序，在一个盒子上dynamic生成未caching的页面内容是一个非常高的命令，只是由于硬件本身的限制。 pipe道只有这么大，没有caching，你会快速填充它们。
看看MSDN博客： 最大限度地增加与IIS6的并发连接数
使用ANTS分析器查找代码中最慢的行。 另外，增加允许的线程数，我想在web.config中。 也许还会增加超时，并从SQL代码中删除函数（如getdate），特别是表值函数。 例如，如果您绝对需要函数在视图中，请使用ODBC转义序列，例如{fn curdate（）}，因为ODBC函数是规范函数（可索引），而普通SQL服务器函数是非确定性的（不可索引）。
如果你得到了一个500响应和一个超时，这表明web服务器正在处理请求，但是需要完成请求的东西超时 – 可能是Web服务器发送到应用服务器的请求。 如果问题出在Web服务器上，那么您将更有可能获得连接失败或networking超时错误（即根本没有HTTP响应），而不是500响应。 我首先看看应用程序和数据库服务器的指标。 如果通常的指标看起来不错，那么查找locking行为。 数据库pipe理员应该在数据库中快速发现这个问题，但是在应用程序服务器代码中（我假设自定义代码），您需要深入挖掘。
我与其他人：你的应用程序可能有问题。 然而，你没有说这个应用程序是否在其他硬件上运行良好（有没有一个开发人员的机器，这是安装的，你可以运行加载亚军？）或不。
话虽如此，如果您认为服务器硬件和/或configuration是可疑的，您可以安装Microsoft .NET Pet Shop 4.0 （用于.NET 2.0应用程序）或者DotNetNuke ，一个开源的.NET内容pipe理系统（CMS）相同的硬件，看看他们如何堆积对抗负载亚军。 如果他们都testing失败，那么也许你的硬件是可疑的（我把它放在另一台机器上testing），或者你的Load Runner的configuration/参数是不正确的，你应该看看那里。