![SQL 连接太慢](https://linux22.com/image/535685/SQL%20%E8%BF%9E%E6%8E%A5%E5%A4%AA%E6%85%A2.png)
我们在 ASP.NET + SQL Server 2008 中有一个商业 Web 应用程序。
一开始 SQL Server 和 IIS 是在同一台机器上。现在我们又买了一台机器。目前的配置是 IIS 机器加 SQL Server 机器,它们通过 1gb LAN 连接。
使用此配置,我们的 Web 应用程序比以前慢。最大带宽是网络的 1-2%,大约 15mbps。
当我们从同一台 IIS 计算机对同一 SQL Server 使用另一个线程时,网络使用率会更高。所以这对 SQL Server 来说没有问题。
我们如何才能为这个 SQL 连接提供更高的带宽?
眼镜:
- .Net 3.5
- SQL Server 2008 标准版
- 文件传输可以100%使用LAN SQL
- 通过 TCP/IP 协议连接 SQL
- 使用启用和测试的登录池
答案1
使用 Profiler 检查在 SQL 实例上运行的查询。
如果应用程序编码不当,您可能会陷入“千刀万剐”的境地,其中有数百或数千个可能无关紧要的小查询返回单行而不是集合或 ed 结果JOIN
。每次应用程序需要这些查询集合之一的数据时,分离层都会在网络连接上引入大量额外延迟。如果您以前没有见过这种情况,这是相当违反直觉的。
在查询量相对较高的服务器上运行 Profiler 可能比较困难,但如果查询量如此之大,您可以将其打开几次,每次 1-2 分钟,并获得良好的样本。无论您做什么,不通过网络连接运行 Profiler。通过 RDP 在 SQL Server 框上运行 Profiler,或将跟踪设置为在实例本身上运行(首选)。
我想你可以投入硬件来减少网络延迟。在我看来,这确实不可扩展,但是如果你正处于需要修复大型应用程序的困境中,这是一个选择,至少是暂时的。
答案2
它们是质量好的服务器,配有不错的网卡吗?廉价网卡(如廉价 RAID 卡)是一种虚假的经济。所有驱动程序都是最新的吗?您必须从一端开始,然后逐步验证所有内容是否具有干净的配置。然后开始故障排除。
您是否为您的进程分配了足够的内存?
总是寻找“不同”的东西。我最近遇到的怪事是一台运行缓慢的高端服务器。CPU、内存充足,没有磁盘活动等。任务管理器显示 120,000 个句柄?!打印机驱动程序每 2 秒就会泄漏一个句柄。
答案3
当 Web 服务器和 SQL Server 位于同一台机器上时,默认shared memory
使用 协议。如果将 SQL Server 移至另一台机器,则通信必须通过 进行TCP/IP
。
基本上,当使用共享内存时,客户端应用程序可以tabular data streams (TDS)
直接从 SQL Server 的内存中读取。当使用 TCP/IP 协议时,必须在服务器上将 TDS 转换为 TCP/IP,发送到客户端,然后再转换回 TDS,这需要时间。
我似乎找不到最新版本的良好参考,但读过这从那时起,情况就没发生太大变化。
如果您的应用程序与 SQL Server 在同一台计算机上运行,请考虑使用共享内存 Net-Library(如果尚未使用)。基于共享内存 Net-Library 的连接通常比其他类型的连接快得多。不过,请记住我之前所说的:在假设解决方案本质上更好或更快之前,请务必彻底测试解决方案并将其与可行的替代方案进行比较。事实胜于雄辩。
和这篇博文也给出了简要概述。更技术性的解释可以在 simple-talk 上找到
答案4
首先在 SQL 框中加载性能监视器 SQL 计数器并进行查看。
.net 应用程序?很有可能它的编写很糟糕,到处都是临时查询。
您是否在使用 100% 存储过程?如果没有,最好有充分的理由。
将 SQL 服务器放在同一个盒子里可能会掩盖之前在应用程序中做出的一些糟糕的设计选择。现在,它们一览无余。
在 56k 调制解调器上,SQL 查询速度非常快,如果只返回结果集。但是,如果您使用客户端游标等方式执行操作,则必须通过网络将所有内容拖回,则不会返回结果集。