【发布时间】：2020-08-14 01:17:44
【问题描述】：
您好，我遇到了关于逻辑应用和 Azure 服务总线队列的性能问题。
所以我有一个看起来像这样的逻辑应用：
（注意：延迟是为了模拟一堆需要大约 2 秒才能运行的连接器/操作，我也在使用锁定令牌和会话 ID 来完成消息和关闭会话）
它每秒轮询一次服务总线以获得高吞吐量并使用峰值锁定 因为我的服务总线队列使用会话在我的流程中启用 FIFO 排序。 所以我正在做的是，向我的服务总线发送大约 2000 条具有不同会话 ID 的消息，以及一些相似的消息，因为它们有时彼此相关（母鸡 fifo）。
在所有消息都在队列中后启用逻辑应用程序，我的逻辑应用程序一次只处理 10 条消息。换句话说，它最多只能同时运行 10 次。
这太慢了，因为这 2000 条消息大约需要 15 分钟来处理。 每次运行大约需要 2-4 秒，一次运行 10 次，具体取决于最后 2 个连接器，每个连接器最多可能需要 1 秒来完成消息并关闭会话。
我做了什么来尝试解决这个问题，例如：
-
运行“当队列中收到一条或多条消息时（峰值锁定）”，而不是将消息计数传递提高到 175（最大值）。这仍然导致只有一条消息被轮询，猜测这与为队列启用的会话有关。
-
在逻辑应用上打开“高吞吐量”，导致最多只能同时运行 10 个实例，有时甚至更少。
-
关闭（甚至打开并定义最大值）逻辑应用触发器上的“并发控制”开关。还是一样的结果。
-
将服务总线扩大到标准层，仍然没有运气。
-
尝试克隆相同的逻辑应用最多 5 次并行运行它们，仍然是相同的结果。
还有更多……
（值得一提，消息不大于 1,5kb - 1,8kb）
我错过了什么？我想不出任何其他要更改的配置，或者使用逻辑应用程序和启用会话的服务总线队列的这种组合来尝试下一步的任何其他想法。我什至应该将服务总线升级到高级版吗？我认为这不值得，因为我还没有达到标准层的限制。
如果我忘记发布任何有用的数据，请告诉我，我会编辑问题。
编辑：
2018-04-06 10:00
我现在尝试了一种“顺序护航”类型的解决方案，但结果更糟：
我按照本指南进行了一些修改：Sequential Convoy Guide
我所做的修改是放置一个“for each”循环而不是“do until”。 这个解决方案的问题是“获取队列中的所有消息”操作大约需要 30 秒才能在队列中搜索包含定义的会话 ID 的消息，这已经很多了。这也导致了一种奇怪的行为，这使得逻辑应用程序的并行运行规模也减少了。
2018-04-06 16:00
我现在尝试的另一个测试是尝试跳过服务总线来测试逻辑应用程序的实例扩展，并确保通过逻辑应用程序中的 Http Post 触发器直接从 API 发布到逻辑应用程序，逻辑应用程序运行中间有服务总线的更多实例。
这意味着是服务总线队列限制了逻辑应用运行的实例数量。
我找不到任何解决此问题的方法，即使尝试将逻辑应用克隆到从同一个队列中提取的多个数量...
对此有什么想法吗？
【问题讨论】：
-
看看这个问题，和sessionstackoverflow.com/questions/49370957/…有关
-
为了增加吞吐量，我建议你使用带有servicebus的eventgrid，然后调用一个http触发逻辑应用程序，不知道它是否适合你？
-
我想这是有道理的，我认为 :P ，但这真的会增加吞吐量吗？我的意思是感觉（当然在阅读之后）事件网格只是集成流中累积时间的另一个补充。感觉瓶颈是服务总线和逻辑应用程序之间的东西，但是如果我在这里错了，请纠正我，我对这种状态全神贯注。并感谢您的回答。 :) @Thomas
-
似乎吞吐量相当不错：每秒 1000 万个事件 (stackoverflow.com/a/48629117/4167200) 所以你将消息推送到服务总线，通过 eventgrid 获取它，然后从 eventgrid 调用一个 http 触发逻辑应用程序（使用高吞吐量），它应该可以解决问题。您将受到逻辑应用程序吞吐量的限制，但应该没问题，您认为呢？
-
这听起来像是一个可以接受的答案吗？
标签： performance azure azureservicebus azure-logic-apps