今天晚上我们观察的排队时间非常慢。我们的跟踪数据告诉我们该行
await queueClient.SendAsync(message);
需要45-60秒。这发生在已经存在很长时间的两个队列中。他们几乎没有超过1-2个记录，我们使用带有ServiceBusTrigger的Web作业来完成工作。我们在队列中放置了一个简单的POCO。还有另一个队列正在快速排队，所以由于缺乏任何其他想法，我删除了两个很麻烦的队列。当代码重新创建它们（因为它构建时），它们在不到一秒的时间内开始排队。没有其他任何改变，期望删除旧队列和重新创建旧队列。我之前和之后使用了服务总线浏览器（我希望我已经截取了屏幕截图）并且据我所知没有任何改变。
知道为什么会出现这样的放缓或为什么重新创建会让它清理干净？我们做的这么低的东西，因为它只是一个试验系统。
谢谢！
戴夫
答案 0 :(得分：7)
我们最近也遇到了与Servicebus非常相似的问题。我们经历了10-20秒的减速，几周后问题突然消失了。我们与Servicebus团队保持密切联系，他们只能说Servicebus是一个共享系统，而SLA只保证可用性而不是性能。
对于任何考虑使用Servicebus的人来说，这应该是一个大开眼界！
答案 1 :(得分：3)
我们对队列进行了分区，然后删除了重复检测，事情变得更好了。微软承认存在锁定问题，他们正致力于解决方案。重复检测会将您的队列限制为一个分区，因此仅此一项没有区别。他们告诉我，当修复程序应用时，他们会提醒我们，我们将尝试再次启用重复检测。
希望这有帮助！ 戴夫
答案 2 :(得分：1)
当队列可能为空时，我们遇到的一个noob陷阱是在Receive上放置一个很长的超时。我们发现它在接收之前要快check the message count。