我们正在尝试启动并运行一个新的 Web 服务器,但是在尝试查询我们的 SQL 服务器时性能却非常糟糕。
新的 Web 服务器是一个 HyperV 虚拟机,运行 Server 2008 R2 64 位、IIS 7.5,具有 3GB 内存。
我们的 SQL Server 是专用的 Server 2003 64 位机器,具有 4 个物理处理器和 16GB RAM,运行 SQL 2005。
新的 Web 服务器和现有的生产 Web 服务器均位于各自独立的 DMZ 中
我们现有的生产 Web 服务器和所有开发客户端都可以毫无问题地访问 SQL 服务器,但是在这些机器上不到一秒就能运行完的查询在新测试服务器上却需要 5 分钟才能运行完。
我们已经验证了它具有正确的 SQL 客户端协议,并打开了 Web 服务器和 SQL 服务器之间的防火墙,但查询仍然需要很长时间。不确定下一步该做什么。想想如果是防火墙问题,查询根本无法运行。
对于下一步该寻找什么,有什么建议吗?
答案1
这最终与 Windows Server 2008 的 TCP 窗口缩放“功能”有关。一旦我们禁用此服务,查询(以及所有其他网络流量)就会运行得更快。
http://www.intel.com/support/motherboards/server/sb/CS-030717.htm
答案2
更多信息可能会有所帮助:
您的查询需要 x 秒,并且根据旧环境预计需要 y 秒,等等。假设您的查询使用搜索参数,适当的索引已到位,索引统计信息是最新等等。
您可以发布一个示例查询吗?
答案3
select * from core_person where last_name = 'turner'
网络应用程序是否偶然运行:
select * from core_person where last_name = @last_name;
并传入类型为nvarchar
? 的 @last_name 变量。这是 ADO.Net 中非常常见的错误,并且可能会在简单的 中被忽视sqlCommand.Parameteres.AddWithValue("@last_name", someStringVariable);
。结果是灾难性的,因为数据类型优先级规则明确指出,比较必须在 NVARCHAR 类型之间进行,因此查询等效于,select * from core_person where cast(last_name as NVARCHAR(...)) = @last_name;
并且这会忽略任何现有索引last_name
并强制进行表扫描。从 SSMS 窗口运行类似的查询运行完全正常,因为在这种情况下不会强制转换。
这只是瞎猜,而且鉴于您完全没有进行调查,所以只能提供这些。我建议您遵循完善的性能故障排除方法,例如等待和排队。