Azure流分析太慢-时间值也没有意义

Question

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

我们根据执行某些测试的需求添加了一些Azure平台（目前它们的用途并不重要）。结构如下：

SimpleApp（发送请求，不在Azure中）->事件中心1（EH1）-> ASA->事件中心2（EH2）->功能应用（FA）

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

当我们从TESTSERVER日志中看到结果时，我们感到震惊。花了4000-5000ms！

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

无论如何，在此之后，我们怀疑最后一个Azure Function App可能会导致这种缓慢。我们认为功能应用程序的事件中心触发器可能无法正常运行。因此，我们设计了一个新的测试环境：

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

第二次震撼...总共只花了约400毫秒！

然后，我们使用包含ASA的不同体系结构执行了许多测试，但是所有这些对于我们来说都太慢了。

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

最好的祝福。

Answer 1

从事件中心按时间顺序合并所有事件时会出现延迟。

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

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

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

可在此处的流分析博客 中找到更多信息。