Azure服务总线队列非常慢
今天晚上，我们观察到排队时间非常慢。我们的追踪数据告诉我们
await queueClient.SendAsync(message);
需要45-60秒。这种情况发生在两个已经存在很长时间的队列上。他们几乎从来没有超过1-2条记录，我们使用一个带有服务总线触发器的网络作业来完成任务。我们正在排队等候一个简单的POCO。还有另一个队列正在快速排队，所以由于没有任何其他想法，我删除了两个麻烦的队列。当代码重新创建它们时（正如它被构建时所做的那样），它们在不到一秒钟的时间里开始排队。没有其他改变，期望删除旧队列和重新创建旧队列。我在使用服务总线浏览器之前和之后（我希望我拍了一张截图），据我所知没有任何变化。
你知道为什么会出现这样的减速，或者为什么重新创造会让它变得清晰吗？我们在做这种小容量的东西，因为它只是一个试验系统。
谢谢！
戴夫
共有3个答案
我们陷入的一个noob陷阱是，当队列可能为空时，在接收时设置长时间超时。我们发现在接收之前检查消息计数要快得多。
我们对队列进行了分区，然后删除了重复检测，情况就好多了。微软承认存在锁定问题，他们正致力于解决这些问题。重复检测将队列限制在一个分区内，因此仅此一项并没有什么区别。他们告诉我，他们将在应用修复程序时提醒我们，我们将再次尝试启用重复检测。
希望这有帮助！戴夫
最近，我们在Servicebus上也遇到了类似的问题。我们经历了10-20秒的减速，几周后问题突然消失。我们与Servicebus团队关系密切，他们只会说Servicebus是一个共享系统，SLA只保证可用性而不保证性能。
这对任何考虑使用Servicebus的人来说都应该是一件大开眼界的事！
-
我正在使用azure服务总线主题和订阅机制，并希望处理所有在死信队列中的消息。 此外，我想通过C#中的Azure Web作业处理消息，并将其发送回队列。所以我想知道如何通过我的应用程序处理死信队列上的消息？
-
我有一个服务总线Q，从Azure门户可以或多或少地看到服务总线Q包含多少条目。如何使用他们的管理API获取此计数？我仔细阅读了文档，但没有找到答案。
-
使用WebJobs SDK时，将代理消息移动到死信队列的正确方法是什么？通常我会打电话给味精。死信（）。但是，SDK负责管理代理消息的生命周期。它将调用msg。如果方法返回成功，则返回Complete（），如果发生异常，则将重试该消息。我需要第三种情况，告诉ServiceBus队列将消息移动到死信队列，因为它是一条坏消息。
-
我有一个windows服务，它侦听Azure服务总线队列消息，以便从我的WebApi应用程序分发处理。此外，我还需要处理重复性任务（每晚/每周），我认为最好使用相同的系统来处理这些任务。 例如，假设我有一个“CleanupDb”队列，每天午夜删除过时的DB节点： 理论上这应该行得通，但我觉得我错过了一个更明显的处理方法。有没有更好的办法？
-
一旦部署到云，我无法从Azure网站访问Azure服务总线队列。在localhost上运行时，如果工作正常，我可以向队列发送消息，但如果我部署应用程序，在远程服务器上创建QueueClient时会出现异常： “套接字连接被中止，因为对套接字的异步发送未在分配的超时00:00:59.4820817内完成。分配给此操作的时间可能是更长超时的一部分。” 我正在使用QueueClient。CreateFr
-
我一直在尝试创建一个客户端来连接我的Azure服务总线队列。我一直在参考此文档： https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-java-how-to-use-queues#send-消息到队列。 我的代码： 在创建客户端时，我遇到以下错误： 通用域名格式。微软蔚蓝色的服务总线。原语。Service