Azure服务总线队列极其缓慢

Question

今晚我们观察到排队时间非常慢。我们的跟踪数据告诉我们，队列

await queueClient.SendAsync(message);

队列在处理时需要 45-60 秒。这种情况发生在两个长期存在的队列中。它们几乎从不超过 1-2 条记录，我们使用 Web Job 和 ServiceBusTrigger 来处理。我们将一个简单的 POCO 放入队列中。还有另一个队列能够快速排队，所以我只好删除了那两个存在问题的队列。当代码重新创建它们（按照设计）后，它们开始在不到一秒的时间排队。除了删除旧队列并重新创建旧队列，没有其他变化。我之前和之后都使用了 Service Bus Explorer（我希望我已经截屏），据我所知，没有发现任何变化。

请问为什么会出现如此缓慢的情况，或者重建队列为什么可以清除这个问题？因为这只是一个试点系统，我们处理的数据量很少。

谢谢！

Dave

- HaukiDog

---

我们遇到了非常相似的问题。任何建议都将非常有帮助。 - Alex Yakunin

+1 我们之前也遇到过这个问题。在重新创建队列后，一切都按预期开始工作了。 - mhertis

一样的情况，在半年之后，性能仍然非常差。 - TTT

这周我也遇到了类似的问题。重新创建队列解决了我的问题。不幸的是，这是我所知道的唯一修复方法，而当你试图处理成千上万条信息时，这并不总是可行的。 - MattM

Answer 1

我们最近也遇到了与Servicebus非常相似的问题。我们经历了10-20秒的减速，几周后问题突然消失了。我们与Servicebus团队有密切联系，他们只会说Servicebus是一个共享系统，SLA仅保证可用性而不保证性能。 这应该让考虑使用Servicebus的人们警醒！

- Mikee

Answer 2

我们对队列进行了分区并移除了重复检测，效果明显改善。微软承认存在锁定问题，并正在寻求解决方案。重复检测将限制队列到一个分区，因此仅此操作不会产生任何差异。他们告诉我，在修复程序应用后会通知我们，我们将尝试重新启用重复检测。

希望这能帮到您！ Dave

- HaukiDog

Answer 3

我们掉进的新手陷阱是在队列可能为空时将Receive设置为长时间超时。我们发现在接收之前检查消息计数要快得多。

- OutstandingBill