逻辑应用和服务总线队列未正确扩展逻辑应用运行实例

Question

我有关于Logic Apps和Azure Service总线队列的性能问题。

所以我有一个逻辑应用程序看起来像这样：

（注意：延迟是为了模拟一系列连接器/操作，运行大约需要2秒，我也使用锁定令牌以及会话ID来完成消息和关闭会话）

它每秒轮询服务总线以获得高吞吐量和峰值锁定 因为我的服务总线队列使用会话在我的流程中启用FIFO排序。 所以我正在做的是，发送大约2000条带有不同会话ID的消息，还有一些类似于消息的消息，因为它们有时（母鸡是fifo）与我的服务总线相关。

在所有消息都在队列中后启用Logic应用程序，我的Logic App一次只处理10条消息。换句话说，它只能同时扩展到10次运行。

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

我尝试通过尝试解决此问题：

• 运行＆＃34;在队列中接收到一条或多条消息（峰值锁定）＆＃34; 而消息计数传递最多可达175（最大值） 。结果仍然只有一条消息被轮询，猜测这与为队列启用的会话有关。

• 开启＆＃34;高吞吐量＆＃34;在逻辑应用上，无论如何最多只能同时运行10个实例，有时甚至更少。

• 关闭（甚至在定义了最大值时打开）＆＃34;并发控制＆＃34;的开关。关于逻辑应用程序的触发器。结果仍然相同。

• 将服务总线扩展到标准层，仍然没有运气。

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

以及更多..

（值得一提的是，消息不超过1,5kb - 1,8kb）

我缺少什么？我无法想到要更改的任何其他配置，或使用逻辑应用程序和会话启用的服务总线队列的组合来尝试下一步的任何其他想法。我甚至可以将服务总线升级到高级版吗？我并不认为这是值得的，因为我还没有达到标准等级的限制。

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

修改

2018-04-06 10:00

我现在如何尝试一种“顺序车队”类型的解决方案，结果更糟糕：

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

我所做的修改是为每个＆＃34;循环而不是＆＃34;直到＆＃34;。 这个解决方案的问题在于它将所有消息排在队列中并且＃34;动作大约30秒来搜索包含已定义会话ID的队列中的消息，这是很多方法。这也导致了一种奇怪的行为，这使得逻辑应用程序也可以缩减并行运行。

2018-04-06 16:00

我现在尝试的另一个测试是尝试跳过服务总线来测试逻辑应用程序的实例扩展，并确保通过逻辑应用程序中的Http Post触发器直接从API发布到Logic应用程序，逻辑应用程序运行服务总线介于两者之间的更多实例。

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

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

有关于此的任何想法吗？

Answer 1

这里很少有建议/输入，请告诉我们是否有帮助。

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

Answer 2

我遇到了同样的问题。 解决该问题的一种可能方法是克隆Logic App。 多个Logic App副本有助于显着提高窥视锁定模式下的消费速度。