performance - 逻辑应用和服务总线队列无法正确扩展逻辑应用运行实例

Question

您好，我遇到了有关逻辑应用和 Azure 服务总线队列的性能问题。

所以我有一个如下所示的逻辑应用程序:

(注意:延迟是为了模拟一堆连接器/操作，大约需要 2 秒才能运行，而且我还使用锁定 token 和 session ID 来完成消息并关闭 session )

它每秒轮询服务总线以获得具有峰值锁定的高吞吐量因为我的服务总线队列使用 session 在我的流程中启用 FIFO 排序。所以我正在做的是，向我的服务总线发送大约 2000 条具有不同 session ID 的消息，以及一些相似的消息，具体取决于消息，因为它们有时彼此相关(即 fifo)。

在所有消息都放入队列后启用逻辑应用，我的逻辑应用一次仅处理 10 条消息。换句话说，它最多只能同时运行 10 次。

这太慢了，因为处理这 2000 条消息大约需要 15 分钟。每次运行大约需要 2-4 秒，一次运行 10 次，具体取决于最后 2 个连接器，每个连接器最多需要 1 秒才能完成消息并关闭 session 。

我已经做了什么来尝试解决这个问题，例如:

• 运行“当队列中收到一条或多条消息时(峰值锁定)”，而传递的消息计数增加到 175(最大值)。这仍然导致只有一条消息被轮询，猜测这与为队列启用的 session 有关。

• 在逻辑应用上启用“高吞吐量”，导致最多只能同时运行 10 个实例，有时甚至更少。

• 关闭(甚至在定义最大值的情况下打开)逻辑应用触发器上的“并发控制”开关。结果还是一样。

• 将服务总线扩展到标准层，但仍然没有成功。

• 尝试克隆同一逻辑应用最多 5 次并行运行它们，结果仍然相同。

还有更多..

(值得一提的是，消息不大于 1,5kb - 1,8kb)

我错过了什么？我想不出要更改的任何其他配置，或者使用逻辑应用程序和启用 session 的服务总线队列的组合来尝试下一步的任何其他想法。我是否应该将服务巴士升级为高级巴士？我认为这不值得，因为我还没有达到标准层的限制。

如果我忘记发布任何有用的数据，请告诉我，我将编辑问题。

编辑:

2018-04-06 10:00

我现在尝试了一种“顺序护航”类型的解决方案，但结果却更糟:

我按照本指南进行了一些修改:Sequential Convoy Guide

我所做的修改是放置一个“foreach”循环而不是“dountil”。此解决方案的问题在于，“获取队列中的所有消息”操作需要大约 30 秒才能在队列中搜索包含定义的 session ID 的消息，这太长了。这也导致了一种奇怪的行为，使得逻辑应用程序也减少了并行运行的规模。

2018-04-06 16:00

我现在尝试的另一个测试是尝试跳过服务总线来测试逻辑应用程序的实例扩展，并且果然通过逻辑应用程序中的 Http Post 触发器直接从 API 发布到逻辑应用程序，逻辑应用程序运行还有更多实例，中间有服务总线。

这意味着它是服务总线队列限制逻辑应用运行的实例数量。

我找不到任何可以解决此问题的方法，即使尝试将逻辑应用程序克隆到从同一队列提取的多个金额...

对此有什么想法吗？

Answer 1

这里有一些建议/意见，如果有帮助请告诉我们。

1. 您可以在下一个可用 session 中使用“当队列中的一条或多条消息窥视锁定时”，而不是当一条消息触发时，批量触发将提高性能。
2. “获取 session 消息”操作使用长轮询并等待 30 秒消息出现在队列中。如果 30 秒内没有消息，则不会执行接下来的操作。如果队列中有任何可用消息，它们将立即返回。
3. 顺序车队的实现可以在此处进行改进。它可以查找同一 session 的更多消息。如果您认为有更多消息可以立即处理，请使用 do-until 并根据博文中提到的任何条件继续接收更多消息。