我们有一个消费计划函数应用程序，它通过ServiceBusTrigger（函数为v4，.net 6）消费来自服务总线的消息。尽管消息的处理几乎是即时的，但我们每分钟只消费来自服务总线的8条消息。
我们已经向Azure提出了这个问题，他们很有帮助，但也在这里伸出援手，因为我们很困惑世界各地的其他人为什么没有遇到同样的问题。
服务总线有一个默认设置为8的“MaxConcurrentSessions”配置。这意味着如果您从启用了会话的订阅中使用，则每分钟只能处理8条消息（这当然非常慢）。
我们遇到了一些错误，即使设置了这个设置也没有得到遵守-但我们想知道其他人是否遇到了同样的问题？人们最终是否完全放弃了服务总线会话，或者人们是否能够在上述限制下获得良好的性能？
1条答案
按热度按时间pod7payv1#
触发器当前使用的Service Bus SDK包有一个错误，该错误将会话的并发性错误地绑定到用于接受会话的同步点。因此，仅对首次接受会话时可读取的消息并发执行处理;在该点之后到达的任何消息都不荣誉并发性。
昨天通过#33035修复了这个问题，但是在下一个预定的发布窗口（目前是2月初）之前不会有稳定的包。
与此同时，降低host.json settings中的
sessionIdleTimeout值可能会有所帮助。sessionIdleTimeout的默认值是使用tryTimeout，该值为60秒，除非被覆盖。降低该值将更快地循环会话，这将有助于提高吞吐量。