6

我们希望将我们的专用服务器迁移到 Azure 平台，以便轻松扩展，并调查了许多 Azure 服务以满足我们的需求。因此，我们想要使用的 Azure 服务之一是 Azure 流分析 (ASA)。

我们根据执行某些测试的需要添加了一些 Azure 平台（现在它们的用途并不重要）。这是结构：

SimpleApp（发送请求，不在 Azure 中）-> 事件中心 1 (EH1) -> ASA -> 事件中心 2 (EH2) -> 函数应用程序 (FA)

  • SimpleApp向名为TESTSERVER的经典专用服务器发送一个简单的 HTTP GET 请求。它最多需要 100-150 毫秒，它代表我们的开始时间。之后，它将消息发送到 EH1。
  • ASA 的查询很简单，如下所示：SELECT * INTO [Output] FROM [Input]
  • Function App向TESTSERVER发送一个简单的 HTTP GET 请求以识别完成时间。

当我们从TESTSERVER日志中看到结果时，我们感到震惊。需要4000-5000毫秒！

然后我们开始调查这个问题。检查EventEnqueuedUtcTime和EventProcessedUtcTime等值，以确定是哪个块导致了这种缓慢。但是这些时间值是完全无关的。例如; EventEnqueuedUtcTime应该小于EventProcessedUtcTime但不是！因此，这向我们表明，即使在不同的 Azure 块中，时间服务器也可能不同，我们无法使用它们来衡量。我错了吗？

无论如何，在这之后我们怀疑也许最后一个Azure Function App可能会导致这种缓慢。我们认为可能 Function App 的事件中心触发器无法正常工作。所以我们设计了一个新的测试环境：

SimpleApp（发送请求，不在 Azure 中）-> 事件中心 1 (EH1) -> 函数应用 (FA1) -> 事件中心 2 (EH2) -> 函数应用 2 (FA2)

第二次震惊……总共只用了大约 400 毫秒！

然后，我们使用包含 ASA 的不同架构进行了很多测试，但它们对我们来说都太慢了。

您是否遇到过 ASA 的任何性能问题？您能否分享您的经验和流程的总时间消耗？

此致。

4

1 回答 1

5

从事件中心按时间顺序合并所有事件时存在延迟。

ASA 将从 EH 访问所有分区，获取数据并将事件按时间顺序组织。这意味着数据必须到达 EH 中的所有分区。我认为这也将解释您在 EventProcessedUtcTime 中看到的奇怪行为，可能是因为事件是有序的，逻辑处理时间在实际到达时间之前。虽然我不确定这一点，因为我不知道 ASA 的内部运作。

这种延迟会随着使用的分区数量的增加而增加，尤其是当数据流很慢时。

partitionid您可以通过从 EH中对字段进行分区来回避合并。确保您也将数据发送到 EH 中的正确分区。

可以在流分析博客上找到更多信息。

于 2016-06-27T01:11:20.497 回答