我们希望将我们的专用服务器迁移到Azure平台，以便轻松扩展，并根据我们的需求调查了大量Azure服务 . 因此，我们要使用的Azure服务之一是Azure流分析（ASA） .
我们根据我们执行某些测试的需要添加了一些Azure平台（目前它们的用途并不重要） . 这是结构：
SimpleApp (Sending Request, Not In Azure) -> Event Hub 1 (EH1) -> ASA -> Event Hub 2 (EH2) -> Function App (FA)
-
SimpleApp 将一个简单的HTTP GET请求发送到名为 TESTSERVER 的经典专用服务器 . 它耗时最多100-150毫秒，它代表了我们的开始时间 . 之后，它将消息发送给EH1 .
-
ASA's 查询很简单，如下所示：SELECT * INTO [Output] FROM [Input]
-
Function App 向 TESTSERVER 发送一个简单的HTTP GET请求以识别完成时间 .
当我们看到 TESTSERVER 日志的结果时，我们感到震惊 . 耗时4000-5000毫秒！
然后我们开始调查这个问题 . 选中的值如 EventEnqueuedUtcTime 和 EventProcessedUtcTime 来识别哪个块导致这种缓慢 . 但这些时间 Value 完全无关紧要 . 例如; EventEnqueuedUtcTime 应该小于 EventProcessedUtcTime 但不是！因此，这表明即使在不同的Azure块中，时间服务器也可能不同，我们无法使用它们进行测量 . 我错了吗？
无论如何，在此之后，我们怀疑可能最后的 Azure Function App 可能导致这种缓慢 . 我们认为功能应用程序的事件中心触发器可能效果不佳 . 所以我们设计了一个新的测试环境：
SimpleApp (Sending Request, Not In Azure) -> Event Hub 1 (EH1) -> Function App (FA1) -> Event Hub 2 (EH2) -> Function App 2 (FA2)
第二次震惊......总共花了大约400毫秒！
然后，我们用不同的架构进行了很多测试，其中包含ASA，但它们对我们来说都太慢了 .
您是否遇到过ASA的任何性能问题？您能否分享一下您的经验和流量的总时间消耗？
最好的祝福 .
1 回答
从事件中心按时间顺序合并所有事件时存在延迟 .
ASA将访问EH的所有分区，获取数据并按事件顺序组织事件 . 这意味着数据必须到达EH中的所有分区 . 我认为这也将解释您使用EventProcessedUtcTime看到的奇怪行为，可能是因为事件是有序的，逻辑处理时间是在实际到达时间之前 . 虽然我对此不确定，因为我不知道ASA的内部运作方式 .
此延迟将随着使用的分区数量而增加，尤其是在数据流速度较慢时 .
您可以通过在EH字段
partitionid上进行分区来回避合并 . 确保您也将数据发送到EH中的正确分区 .更多信息可以在Stream Analytics blog找到 .