使用远程 Azure SQL 数据库的糟糕表现

Question

我们目前正在评估 Azure 的 SQL 数据库服务（与本地安装相比），因为我们希望将“始终加密”功能集成到我们的（基于 Java 的）应用程序中。

问题是，表演很糟糕。

我正在从位于同一地区（巴黎）的物理服务器连接到在“法国中部”地区创建的数据库。

我编写了一个非常简单的 java 应用程序，它在一个非常简单的表中执行 5000 次插入（准备好的语句），它使用 Microsoft jdbc 驱动程序和 Azure 提供的连接字符串。

无论我使用什么类型的 SQL 数据库（最后一次使用 S6 标准测试），都需要将近一分钟才能完成。Java 应用程序在生产服务器（8 核）上运行。我希望使用远程数据库会有一些延迟，但不会达到这个级别。（相同的测试在 5 秒内使用本地服务器上的 SQL Server 运行）。

这是意料之中的吗？我虽然我们的案例是由 SQL 数据库服务（远程 SQL 服务器）解决的案例。我还在同一个区域创建了一个VM，通过数据库的公共IP连接，它几乎一样糟糕。我尝试在其他欧洲国家创建 SQL 数据库，结果更糟。

Answer 1

似乎有道理。特别是如果插入是串行运行的。分解它：

假设应用程序和数据库服务器之间有 30 毫秒的 RTT。由于 SQLServer 是符合 ACID 的数据库，并且数据库驱动程序遵守这一点，因此理论上的最大 TPS 量为每秒 33，因为驱动程序将阻塞，直到它收到来自数据库的 ACK。(1000ms / 30ms = ~33 TPS)

您实现了大约 83 TPS，所以我猜应用服务器和数据库之间的延迟大约是 12 毫秒。

在本地服务器上，您可能有亚毫秒的计时。

远程数据库只是一个坏主意。但是，如果必须这样做，请尝试将操作批处理到单个事务中，因为您可以将更多数据打包到 RTT 跃点中。话虽如此，这意味着失败的代价要高得多（重试 1 次插入 vs 重试所有 100 次）。把这一切都考虑在内，但你可以做的任何事情来减少延迟（或增加并行性）都会产生很大的不同。