0

我正在使用 Azure Queue 后端测试 NServiceBus。我使用所有默认设置配置了 NServiceBus，并使用此代码发送消息：

while ((data = Console.ReadLine()) != null)
{
   Stopwatch sw = new Stopwatch();
   sw.Start();
   Bus.Send("testqueue", new Message() {Data = data});
   sw.Stop();
   Console.WriteLine("Sent time: " + sw.ElapsedMilliseconds);
}

在我的开发机器上运行时，将消息发送到队列大约需要 700 毫秒。队列很远，直接使用 Azure 存储客户端写入时约为 350 毫秒。

现在我有两个问题：

  1. 我不希望线程阻塞 Bus.Send 调用。一种选择是使用 async\await 模式。另一种选择是使用内存队列来传递消息，类似于 0MQ。最后一个选项不能保证交付当然，但假设有一些监控功能，我可以接受。
  2. 为什么发送消息需要两倍于简单写入队列的时间？这可以优化吗？
4

1 回答 1

0

数据属性的大小是多少？

我刚刚自己运行了这个测试（使用字符串“Whatever”作为数据），我看到每次远程发送的平均延迟约为 50 毫秒，每 15 秒进行一次油门，使得调用在那时大约需要 300 毫秒（这是预期的） ）。

请注意，azure 存储是基于远程 http 的服务，因此会因距离而受到延迟，据我所知，它在这里也没有公布的性能目标。此外，当数据移动时，它具有主动节流功能，大约每 15 秒发生一次（请参阅我的存储内部讨论以了解幕后发生的事情。http://www.slideshare.net/YvesGoeleven /天蓝色存储深度潜水）

关于异步/等待的主题。如果您的目的是解除对 UI 线程的阻塞，那么请继续这样做......

await Task.Factory.StartNew(() => _bus.Send(new Message{
       Whatever = data
})).ConfigureAwait(false);

如果您的目的是实现更高的吞吐量，则应该使用更多的发送线程，因为无论如何一个线程都需要等待 http 响应，即发送线程或从 async/await 触发的后台线程。但是请注意，无论您使用多少发送威胁，每个队列也会单独受到限制（以数百条消息/秒）

PS：还建议 IT 更改 .net 服务点管理器上的以下设置，以针对大量小型 http 请求进行优化

ServicePointManager.UseNagleAlgorithm = false;
ServicePointManager.Expect100Continue = false;
ServicePointManager.DefaultConnectionLimit = 48;

希望这可以帮助...

于 2014-07-09T08:52:50.430 回答