逻辑应用程序和服务总线队列未正确缩放逻辑应用程序运行实例 [英] Logic app and service bus queue not scaling logic app run-instances properly

问题描述

我遇到了有关Logic Apps和Azure Service总线队列的性能问题.

Hi i have a performance issue regarding Logic Apps and a Azure Service bus queue.

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

So i have a logic app looking like this:

(注意:延迟是用来模拟一堆连接器/操作的，大约需要2秒钟的时间才能运行，另外我正在使用锁定令牌以及会话ID来完成消息和关闭会话)

(NOTE: The delay is there to simulate a bunch of connectors/actions that take about 2 seconds to run, also i'm using lock tokens and also session IDs to complete messages and Close sessions)

它每秒轮询一次服务总线，以达到峰值锁定的高吞吐量 因为我的服务总线队列使用会话在我的流程中启用FIFO排序. 因此，我正在做的是，向我的服务总线发送大约2000条具有不同会话ID的消息，以及一些有时彼此相关的消息，具体取决于该消息.

Its polling the service bus every second for high throughput with a peak-lock because my service bus queue uses sessions to enable FIFO Ordering in my flow. So what i'm doing is, sending about 2000 messages with different session-IDs and also some that are alike depending on the message as they relate to each other sometimes (hens the fifo) to my service bus.

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

Enabling the Logic app after all the messages are in the Queue, my Logic App only processes 10 messages at a time. In other words it only scales up to 10 runs simultaneously.

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

This is far to slow, as those 2000 messages takes about 15 minutes to process. That's about 2-4 seconds per run, 10 runs at a time depending on the last 2 connectors that can take up to 1 second each to complete the message and close the session.

我通过尝试例如以下操作来解决此问题:

What i have done to try to solve this by trying for example:

• 运行当在队列中收到一个或多个消息时(峰值锁定)" ，而不是将消息计数传递提高到175(最大值).这仍然导致只轮询一条消息，猜测这与为队列启用的会话有关.

• Running the "When one or more messages are received in queue (peak-lock)" instead with message count delivery bumped up to 175 (max value). This results still in only one message getting polled, guessing this has to do with the sessions enabled for the queue.

打开高吞吐量"在逻辑应用程序上，无论如何最多只能同时运行10个实例，有时甚至更少.

Turned on "High Throughput" on the logic app, resulting in only up to 10 instances running simultaneously anyway, sometimes even fewer.

将用于并发控制"的开关关闭(甚至以定义的最大值打开).在逻辑应用程序的触发器上.结果还是一样.

Turned off (and even turned on with max value defined) the switch for "Concurrency Control" on the trigger for the logic app. Still same results.

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

Scaled up the service bus to standard tier, still no luck.

试图克隆同一逻辑应用程序，最多并行运行5次，结果仍然相同.

Tried to clone the same logic app up to 5 times running them in parallell, still same result.

还有更多..

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

(Worth mentioning, the messages aren't bigger than 1,5kb - 1,8kb)

我想念什么?我想不出要更改的任何其他配置，或者使用此逻辑应用程序和启用了会话的服务总线队列的这种组合尝试下一个尝试.我是否应该将服务总线升级到高级版?我认为这不值得，因为我还没有达到标准等级的限制.

What am i missing? I can't think of any other configuration to change, or any other ideas using this combination of logic app and session enabled service bus queues to try next. Should i maybe even upgrade the service bus to premium? I didn't think it was worth it because i haven't met the limits for the standard tier yet.

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

If i forgot to post any useful data please tell me and i will edit the question.

2018-04-06 10:00

我现在如何尝试一种顺序车队"类型的解决方案，其结果甚至更糟:

I how now tried a type of "Sequential Convoy" type of solution which yielded in even worse results:

我对本指南进行了一些修改:

I followed this guide with some modifications: Sequential Convoy Guide

我所做的修改是将每个"循环而不是直到". 该解决方案的问题在于，它花费了将所有消息放入队列".大约30秒钟的操作，以在队列中搜索包含已定义会话ID的消息，这很有效.这也导致了奇怪的行为，这也使得逻辑应用程序也无法扩展并行运行.

The modification i did was putting a "for each" loop instead of a "do until". The thing with this solution was that it took the "get all messages in queue" action about 30 seconds to search for a message in the queue containing the defined session ID, which is way to much. This also resulted in a weird behavior which made the logic app to scale less parallel runs too.

2018-04-06 16:00

我现在尝试的另一项测试是尝试跳过服务总线以测试逻辑应用程序的实例扩展，并确保通过逻辑应用程序中的Http Post触发器将足够的内容从API直接发布到逻辑应用程序中，逻辑应用程序将运行中间有服务总线的实例更多.

Another test i tried now was trying to skip the service bus to test the instance scaling of the logic app, and sure enough posting directly from the API to the Logic app by the Http Post trigger in logic app, the logic app runs a lot more instances that with the service bus in between.

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

Which means that it is the service bus queue limiting the amount of instances being run by the logic app.

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

I cant find anything that fixes this problem, even by trying do clone the logic app to multiple amounts pulling from the same queue...

对此有何想法?

推荐答案

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

I came across the same issue. One possible way in which I was able to get around it was by Cloning the Logic App. Multiple copies of Logic App helped in improving the consumption speed in peek-lock mode significantly.

这篇关于逻辑应用程序和服务总线队列未正确缩放逻辑应用程序运行实例的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！