【问题标题】：Same Hasura query executed with hugely different execution times相同的 Hasura 查询以截然不同的执行时间执行
【发布时间】：2021-09-23 15:42:21
【问题描述】：

在定期向 Hasura 服务器发送相同的图形查询时，我观察到执行时间明显不同

在其中一种情况下，查询在 1 秒内执行，而在另一种情况下，同一查询需要 150 多秒。执行时间是从 Hasura “http-log” 语句中捕获的。

从相应的“查询日志”语句中得到的另一个观察结果是，在两种情况下，SQL 都是在相似的时间内生成的。

生成的 SQL 在与其他 SQL 相比显着且相当长的延迟之后执行的任何原因。

此不一致行为的任何具体原因以及可用于解决此问题的任何具体配置。

【问题讨论】：

【解决方案1】：

我不知道这是否算作一个答案，它肯定不是“一般情况下的答案”，因为它只反映了我们的经验。

我们遇到了类似的问题：相同查询的延迟不一致。

我们在哪里寻找和发现了什么。

1.哈苏拉

Hasura 本身是 postgresql 之上的一个非常薄且可预测的层（现在其他数据库也是如此）。

（我可能是错的，如果有人能纠正我，我将不胜感激）

所以：

结论：hasura 本身不可能是不同延迟的来源。我们需要查看数据库级别

2.我们在 DB 级别遇到的情况

我们构建一个简单的测试：在 DB 上运行相同的查询

我们发现相同的查询运行时间为 100ms-100ms-2 秒 - 150 毫秒 - 3 秒 - 90 毫秒。

我们搜索锁 - 但没有找到。

我们查看了缓冲 - 发现几乎所有 DB 都缓存在内存中。

最后我们怀疑是 Azure 数据库（我们使用 MS 的云 postgresql）行为不端。

我们联系了支持人员（我们向他们提出了其他问题），最后我们发现我们只是达到了 IOPS 限制。

这个假设得到了简单事实的支持：如果我们运行 VACUUM/REINDEX/ REFRESH MATERIALIZED VIEW/heavy procedures，那么 DB 在一段时间内的响应速度就会大大降低。

我们考虑升级 Azure 数据库，但遇到了其他问题，我们想升级 postgresql 版本，所以最后我们决定迁移到 Amazon RDS。

（这不是抨击 Azure 或推广亚马逊，我个人认为在本地运行会是最好的）

在那之后，所有奇怪的执行时间都消失了。

想想这如何反映你的情况。

一般来说，我建议只查看数据库级别。

【讨论】：