基于MPLS的SQL性能

Question

GI对SQL在MPLS上的性能有疑问。

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

当然，我们希望构建基于SQL2017标准的集群SQL和用于SQL的带有SSD磁盘的Dell存储数组。有没有人在类似的场景中有经验，并能说出来？

Answer 1

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

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

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

• 好的设计:只带回屏幕所需的最小数据。
• 糟糕的设计:收回整个表，过滤它的客户端(应用程序做了很多这方面的工作)

延迟:如果应用程序管理自己的事务，延迟将是一个问题。一些应用程序启动事务，然后一次给数据库服务器一行以完成一个目标。它们小剂量地处理失败/重试逻辑(而不是存储的proc)。当数据库服务器距离应用程序在1-10毫秒内时，这一点过去是很好的，但是如果您开始将其扩展到50-100 50，对于最终用户来说，事务处理速度会指数级地慢下来。

• 良好的设计:构建一个存储过程，让您的应用程序调用它并提供完成业务事务所需的所有参数。
• 错误的设计:启动一个事务，插入一行，等待数据库服务器确认，然后在另一个表中发送另一个行，另一行一直保持锁打开。

吞吐量:并发性越强，性能就越慢。如果每个办公室的每个人都有完全相同的使用模式--就像他们都在下午1点整从午餐中回来，同时又开始工作一样--那么你的网络管道的吞吐量可能是个问题。现在，您可以开始了解上面的内容是如何开始雪球的:如果您有一个管理自己事务的聊天应用程序，那么它向SQL Server发送/接收所需的数据将更加困难，并且随着共享管道吞吐量的减小，锁将被保持更长的时间。

要对此进行监视，请从今天开始查看每个Server的网络端口利用率。您可以通过Perfmon计数器或任务管理器跟踪它，查看它使用的现有网络端口的百分比，以及它与您提议的MPLS连接之间的关系。