如何在我的开发机上模拟网络延迟？

Question

我正在将一个MS Access 2003应用程序升级到SQL Server后端。在我的开发机器上，SQL Server是本地的，因此性能相当不错。我想使用远程SQL Server来测试性能，这样我就可以考虑重设计应用程序时网络延迟的影响。我期望一些现在看起来很快的查询一旦部署到生产环境中就会运行得相当慢。

如何减慢（或模拟远程）SQL Server的速度，而不使用虚拟机或将SQL移到另一台计算机上？是否有某种代理或Windows实用程序可以为我完成这个操作？

- D'Arcy Rittich

---

只需编写高效的应用程序以检索数据，即一次不要检索超过用户需要或可以处理的数据量。这在任何环境下都是高效的，包括使用Jet/ACE后端。没有什么神奇的地方。唯一可能遇到边缘情况的情况是如果您计划在开放的互联网上运行，在那里带宽相对非常低（与局域网相比）。在这种情况下，您可能会做更多的事情，但我建议不要过早优化 - 使其高效，然后修复速度不够快的问题。 - David-W-Fenton

@David：我正在移植一个非常大的现有MS Access应用程序。我需要在我做出哪些更改方面进行战略规划，没有时间或预算修改每个查询和数据源。 - D'Arcy Rittich

我甚至没有开始建议修改所有内容。如果这是一个设计良好的Access应用程序，它很可能表现非常出色。如果不是，那么就需要大量的工作。仅检索有限数量的记录的原则可以使得无论后端是Jet/ACE还是服务器数据库，都能够快速、高效地运行应用程序。 - David-W-Fenton

@David：我不太确定你在建议什么。你说“编写高效的应用程序”-我正在移植一个现有的应用程序。你说“只检索有限数量的记录的原则可以使应用程序快速高效”-这正是我打算做的，但需要先确定瓶颈在哪里。我的问题不是如何重写查询以提高性能，而是如何确定一旦网络出现，哪些查询将变得缓慢。 - D'Arcy Rittich

我的经验是，现有应用程序中的瓶颈几乎不可能预测。每次我进行升级时，每个应用程序都有一些区域，我认为需要通过将逻辑服务器端移动来处理问题，并且还有一些其他区域，我认为由于原始设计，它们会表现得很好。但是大约50％的时间，瓶颈表现良好，而不会出现问题的区域变成了瓶颈。没有办法在不进行升级和测试的情况下知道这一点。使用与工作站分离的服务器应该足以揭示这些问题。 - David-W-Fenton

可能是模拟缓慢网络连接的网络工具的重复问题。 - blahdiblah

Answer 1

我自己没有使用过，但是这里有另外一个stackoverflow的问题：

• 模拟慢速网络连接的网络工具

在其中的评论中明确提到了SQL Server。

- icyrock.com

Answer 2

你可能存在一个误解。MS-Access支持所谓的“异构连接”（即可以在同一查询中包含来自各种后端的表，例如将来自Oracle、SQLServer、Access和Excel电子表格的数据组合起来）。为了支持这个特性，Access应用WHERE子句过滤器在客户端，除非是针对智能后端的“透传”查询。在SQL Server中，过滤发生在运行在服务器上的引擎中，因此SQL Server通常会向客户端发送更小的数据集。

你的问题的答案也取决于你所说的“远程”的含义。如果你在同一网络上比较Access和SQL Server，运行在服务器上的SQL Server只会消耗很少的带宽，如果Access MDB文件驻留在文件服务器上。（当然，如果MDB驻留在本地PC上，则不会消耗任何网络带宽。）如果你比较局域网上的Access和通过云进行宽带访问的SQL Server，那么你就是在比较名义上的100兆位/秒管道和DSL或电缆带宽，即最好情况下的20兆位/秒名义值，可能还要少得多。

因此，你必须更具体地说明你想要比较什么。

你是在将本地PC上的Access客户端与驻留在文件服务器上的Access MDB进行比较，还是将其他类型的客户端用于从同一网络上另一个服务器中的SQL Server消耗数据？你要继续使用Access作为客户端吗？你的查询是否为传递查询？

- Tim

---

@Time：你的第一个段落是不正确的。对于我在SQL Server上执行的非透传查询，只要没有使用Access特定的关键字，WHERE子句就会在SQL Server上运行。你的第二个段落也是错误的：对于从Access对SQL Server进行的查询，只有在JOIN和WHERE子句可以在SQL Server上运行而没有Access特定的关键字（如'IIF'）的情况下，才会消耗较少的带宽。如果存在Access特定的关键字，整个数据集将被拉到Access中以便在那里运行关键字。 - D'Arcy Rittich

完整数据集是否被获取取决于Access特定的函数使用的位置。在SELECT子句中，这并不是问题，因为所有WHERE条件和JOIN将在服务器上执行，然后在过滤结果集上仅处理SELECT中的函数。但是，如果您在WHERE或JOIN子句或ORDER BY中使用Access特定的函数，则可能会或可能不会拉下整个表格，这取决于Jet/ACE能否在Access特定的函数之前分离出某些限制因素。 - David-W-Fenton

Answer 3

有一个适用于Windows的软件应用程序可以实现这一点（如果需要，模拟低带宽、延迟和丢包）。但它不是免费的。试用版有30秒的仿真限制。这是该产品的主页：http://softperfect.com/products/connectionemulator/

- Andrew Lock

Answer 4

@RedFilter：你应该指明你正在使用的Access版本。这份来自2006年的文档表明，Access通过网络传输到客户端的内容比查询是否包含“Access特定关键字”更加复杂。

http://msdn.microsoft.com/en-us/library/bb188204(SQL.90).aspx

但是随着每个新版本的推出，Access可能越来越精通于使用服务器资源。

我仍然坚持我的简单建议：如果您想要最小化带宽消耗，同时仍然使用Access作为GUI，则通过查询是最好的选择，因为这样你就可以控制通过网络传输的数据量，而不是Access。

我仍然认为您最初的问题/方法是错误的：如果您的Access MDB文件一开始就位于LAN上（是吗？），则无需模拟网络延迟的影响。您需要嗅探Access生成的SQL语句，而不是引入某些任意和恒定的“网络延迟”因素。要比较使用位于LAN服务器上的MDB的Access GUI与针对SQL Server后端的升级Access GUI之间的差异，您需要评估Access从后端服务器向客户端传输的数据。即使是“升级”的Access在不使用通过查询的情况下也可能会成为带宽瓶颈，但是针对SQL-Server后端编写的正确客户端始终比访问位于LAN服务器上的MDB的Access更加节省网络带宽，ceteris paribus。

- Tim

---

当前访问后端MDB位于局域网中。我目前正在嗅探查询。Access的版本是2003。我的理解是，通行查询是只读的，并且我的一些查询需要输入参数。我认为确定应该修复哪些瓶颈的最快方法是通过实证来完成。 - D'Arcy Rittich