MPLS 上的 SQL 性能

Question

GI 对 SQL over MPLS 的性能有疑问。

我有一个有 3 个本地化版本的客户。我们希望将服务器环境集中，并将所有 SQL 数据库迁移到总部。我们的客户端使用基于 SQL Server 2017 标准的应用程序。位置之间是 MPLS 连接 100/100，位置和总部之间的延迟 (ping) 为 5-7 毫秒。我们预计一次将有大约 150 个连接到数据库。我们很担心这件事的表现。

当然，我们要构建基于 SQL 2017 Standard 的集群 SQL 和带有用于 SQL DB 的 SSD 磁盘的 Dell 存储阵列。有没有人有类似场景的经验并且可以告诉它？

Answer 1

通常，您希望应用程序尽可能接近数据库服务器。（不管应用程序和数据库如何，这个建议都是正确的，所以即使我是一个 SQL Server 人，我也会尝试写这个来帮助人们寻找 MySQL、PostgreSQL 等的类似答案。）

网络问题归结为两件事：延迟时的吞吐量。

吞吐量：应用程序移动的数据越多，性能就越慢。如果应用程序只执行小的、有针对性的查询来恢复他们需要的最少行数和列数，那么它会感觉很快。另一方面，如果应用程序在没有过滤的情况下执行 SELECT * FROM TABLE 并且在客户端执行过滤，那么减少的网络带宽可能是一个问题。

• 好的设计：只带回屏幕所需的最少数据
• 糟糕的设计：带回整个表，在客户端对其进行过滤（MS Access 应用程序做了很多）

延迟：如果应用程序管理自己的事务，延迟将是一个问题。一些应用程序开始一个事务，然后一次给数据库服务器一行来完成一个目标。它们以小剂量完成工作，并在其代码中处理失败/重试逻辑（而不是存储过程。）当数据库服务器在应用程序的 1-10 毫秒内时，这曾经很好，但是如果您开始将其延长到 50-100 毫秒，最终用户会感觉交易速度呈指数级增长。

• 好的设计：构建一个存储过程，让您的应用使用完成业务交易所需的所有参数调用它
• 糟糕的设计：启动一个事务，插入一行，等待数据库服务器确认，然后在另一个表中发送另一行，另一行，一直保持锁打开

吞吐量：您拥有的并发越多，性能就越慢。如果每个办公室的每个人都有完全相同的使用模式——比如他们都在下午 1 点吃完午饭回来并同时开始工作——那么你的网络管道的吞吐量可能是一个问题。现在您可以开始看到上述内容如何开始滚雪球：如果您有一个管理自己事务的健谈的应用程序，那么它将更加困难地向 SQL Server 发送/接收它需要的数据，并且锁将是随着共享管道吞吐量变小，保持打开的时间更长。

要对此进行监控，请首先查看当前每个 SQL Server 的网络端口利用率。您可以通过 Perfmon 计数器或任务管理器跟踪它，查看它使用的现有网络端口的百分比 - 以及它与您提议的 MPLS 连接的关系。