在过去的圣诞假期，当我工作的网站的stream量非常低时，我们看到几个请求超时例外（每天一个>> 12/26，12/28，12/29和12/30）在几个需要用户authentication的页面上。 在这个非常低的stream量周之前，我们很less看到Request超时例外。
我们认为超时是由于数据库使用的是SQL Server上的“降速”，并且在请求进入时需要花费更长的时间。
在SQL Server（SQL Server 2005）上有两个数据库，一个专门用于这个应用程序，另一个用于面向公众的网站和authentication; 所以在用户没有login到应用程序的情况下（在圣诞节那一周肯定会有几个小时），应用程序数据库可能没有收到任何请求。 我们认为在这一点上SQL Server重新分配资源到其他数据库，然后当一个请求进来时，需要额外的时间来旋转应用程序数据库，并发生超时。
有没有办法告诉SQL Server在任何时候都向数据库提供最less量的资源？
确保数据库的“自动closures”属性设置为FALSE。
如果这是打开的，那么在低stream量的时候，基本上就要把数据库脱机。 对它的第一个查询会尝试将其重新联机，但取决于大小，可能需要一段时间。
编辑：如果不是这样的话，那么一些其他的事情来检查：
除此之外，我能想到的唯一事情就是优化查询，以便即使在表未被caching时也能以最佳方式运行。
所有正常的性能调整build议当然都适用，包括正确的索引（最好是覆盖索引）等。
在SQL 2008中，使用资源调控器 ：
- 分类传入连接并将其工作负载路由到特定组的能力。
- 监控组中每个工作负载的资源使用情况的能力。
- 集中资源并设置CPU使用率和内存分配的池特定限制的function。 这可以防止或最小化失控查询的可能性。
- 将分组工作负载与特定资源池相关联的function。
- 能够识别和设置工作负载的优先级。
在SSMS（Management Studio）中右键单击对象资源pipe理器中的服务器名称以获取服务器属性。 在select页面部分中selectMemory。 在那里你设置了可用于SQL Server的最小和最大内存。 留出足够的操作系统相关的项目（我通常使用4 GB），然后让其余的可用于SQL Server。 通过旋转和旋转我假设你指的是caching（过程和缓冲区），这可能是一个问题。
希望这可以帮助。
我们认为超时是由于数据库使用的是SQL Server上的“降速”，并且在请求进入时需要花费更长的时间。
你做了什么诊断来得出这个结论？ 确保你正在解决正确的问题，当你正在实施一个解决scheme。