我们试图让一个新的Web服务器启动并运行，但是当试图查询我们的SQL服务器时性能变得糟糕。
新的Web服务器是运行Server 2008 R2 64位，具有3GB内存的IIS 7.5的HyperV虚拟机。
我们的SQL Server是专用的Server 2003 64位机器，具有4个物理处理器和运行SQL 2005的16GB RAM。
新的Web服务器和现有的生产Web服务器都在它们自己的DMZ中
我们现有的生产Web服务器和所有开发客户端都可以毫无问题地访问SQL服务器，但是在这些机器上运行的查询不到一秒钟，需要5分钟的时间才能在新的testing服务器上运行。
我们已经validation了它具有正确的SQL客户端协议并打开了Web服务器和SQL服务器之间的防火墙，但是查询仍然是永久的。 不知道接下来要看甚么。 如果这是一个防火墙问题，那么查询根本就不会运行。
有什么build议下一步要找什么？
这最终与Windows Server 2008的TCP Window Scaling“function”有关。 只要我们禁用此服务，查询（连同所有其他networkingstream量）运行得更快。
http://www.intel.com/support/motherboards/server/sb/CS-030717.htm
多一点信息会有帮助：
你的查询需要花费x秒，而且他们需要基于旧的环境等等。假设你的查询使用search论证，适当的索引到位，索引统计是最新的等等。
你能发表一个示例查询吗？
select * from core_person where last_name = 'turner' networking应用程序是否可以运行：
select * from core_person where last_name = @last_name;
并传入一个types为nvarchar的@last_namevariables？ 这是ADO.Net非常常见的错误，可以通过简单的sqlCommand.Parameteres.AddWithValue("@last_name", someStringVariable);忽略sqlCommand.Parameteres.AddWithValue("@last_name", someStringVariable); 。 结果是灾难性的，因为数据types优先权规则明确规定，必须在NVARCHARtypes之间进行比较，以便查询等价于select * from core_person where cast(last_name as NVARCHAR(...)) = @last_name; 这会忽略last_name上的任何现有索引并强制进行表扫描。 从SSMS窗口运行类似的查询运行非常好，因为在这种情况下不强制转换。
这只是在黑暗中的一个镜头，而且在你方面完全没有调查的情况下，你可以提供一切。 我build议您遵循一个完善的性能故障排除方法，如等待和队列 。