我们有一个消费计划功能应用程序，它通过 ServiceBusTrigger 消费来自服务总线的消息(功能是 v4，.net 6)。尽管消息处理几乎是即时的，但我们每分钟仅消耗来自服务总线的 8 条消息。
我们已经向 Azure 提出了这个问题，他们很乐于助人，但我们也很困惑为什么世界各地的其他人没有遇到同样的问题。
服务总线有一个“MaxConcurrentSessions”配置，默认设置为 8。这意味着，如果您从启用了 session 的订阅中进行消费，则每分钟只能处理 8 条消息(这当然非常慢)。
我们遇到了错误，即使设置了此设置也不受尊重 - 但我们想知道其他人是否也遇到过同样的问题？人们最终是否完全放弃了服务总线 session ，或者即使在上述限制下，人们是否仍能够实现良好的性能？
最佳答案
触发器当前使用的服务总线 SDK 包存在一个错误，该错误错误地将 session 并发性与接受 session 的同步点联系起来。因此，仅对首次接受 session 时可供读取的消息同时执行处理；该点之后到达的任何消息都不支持并发。
昨天已通过 #33035 修复了此问题，但直到下一个预定的发布窗口(目前是二月初)才会以稳定包的形式提供。
与此同时，降低 host.json settings 中的 sessionIdleTimeout 值可能会有所帮助。 。 sessionIdleTimeout 的默认值是使用 tryTimeout，除非被覆盖，否则为 60 秒。降低该值将更快地循环 session ，这应该有助于提高吞吐量。
关于azure - Function App 每分钟仅使用来自启用 session 主题的服务总线 8 条消息，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/74797482/