我们目前正在评估 Azure 的 SQL 数据库服务（与本地安装相比），因为我们希望在我们的（基于 Java 的）应用程序中集成“始终加密”功能。
问题是，表演太糟糕了。
我正在从位于同一地区（巴黎）的物理服务器连接到在“法国中部”地区创建的数据库。
我编写了一个非常简单的 java 应用程序，它在一个非常简单的表中执行 5000 次插入（准备好的语句），它使用 Microsoft jdbc 驱动程序和 Azure 提供的连接字符串。
无论我使用哪种类型的 SQL 数据库（上次测试使用 S6 Standard），它都需要将近一分钟才能完成。Java 应用程序在生产服务器（8 核）上运行。我预计使用远程数据库会有一些延迟，但不会达到这个水平。（在本地服务器上使用 SQL Server 进行相同的测试需要 5 秒）。
这是预料之中的吗？我认为我们的情况是 SQL 数据库服务（远程 SQL 服务器）解决的情况。我还在同一地区创建了一个 VM，通过数据库的公共 IP 进行连接，情况几乎一样糟糕。我尝试在其他欧洲国家/地区创建 SQL 数据库，但情况更糟。
答案1
看起来合理。特别是如果插入是串行运行的话。分解一下：
假设应用程序和数据库服务器之间的 RTT 为 30ms。由于 SQLServer 是符合 ACID 的数据库，并且数据库驱动程序也遵守这一点，因此理论上的最大 TPS 量为每秒 33，因为驱动程序将阻塞直到收到来自数据库的 ACK。（1000ms / 30ms = ~33 TPS）
您实现了大约 83 TPS，因此我猜测应用服务器和数据库之间的延迟大约为 12ms。
在本地服务器上，您可能会有亚毫秒级的计时。
远程数据库是个坏主意。但如果必须这样做，请尝试将操作批量处理为单个事务，因为您可以将更多数据打包到 RTT 跳转中。话虽如此，这意味着失败的代价要高得多（重试 1 次插入与重试所有 100 次插入）。请考虑所有这些因素，但您可以采取的任何减少延迟（或增加并行性）的措施都会产生重大影响。