【发布时间】：2017-12-19 08:11:01
【问题描述】：
我们正在检查 Azure 服务总线，以将其用作我们的本地服务总线。我们正在测试往返时间，它似乎在 10 毫秒到 2000 毫秒之间波动。平均而言，它约为 100-200 毫秒。似乎有一个预热时间，从 2 秒到更高负载下的 200 毫秒。
有什么方法可以缩短平均往返时间？
使用高级层有帮助吗？ --> （编辑：没有帮助。使用 1 个消息单元，实际上高级层的平均值更差）
我们的设置：
- 消费者 (PC#1)
Producer (PC#2)（注意：这两台计算机在同一个本地网络上）
Azure 服务总线（实际上是在 azure 上）
旁注/趣闻：距离微软数据中心 1500 公里。光速使用约 10 毫秒往返。
测试 1：
- 消息数：每分钟 1000 条
- MaxConcurrentCalls：1
- 操作：接收和删除消息
- 预取计数：0
- 开始平均。 1-2秒
- 结束平均。 100-200ms
- 输出：Pastebin link
样本输出：
20; 2017-12-07T11:41:48.5134157+01:00; 2017-12-07T11:41:48.7781795+01:00; 264,7638
3; 2017-12-07T11:41:47.4827021+01:00; 2017-12-07T11:41:48.8378167+01:00; 1355,1146
14; 2017-12-07T11:41:48.1491488+01:00; 2017-12-07T11:41:48.8950421+01:00; 745,8933
0; 2017-12-07T11:41:47.2250519+01:00; 2017-12-07T11:41:48.9518713+01:00; 1726,8194
测试 2：
- 消息数：每分钟 1000 条
- MaxConcurrentCalls: 1000
- 操作：接收和删除消息
- 预取计数：0
- 开始平均。 1-2秒
- 结束平均。 100-200 毫秒（注意：峰值可达 20 秒）
- 输出：Pastebin link
样本输出：
4; 2017-12-07T11:43:43.5735023+01:00; 2017-12-07T11:43:44.7905668+01:00; 1217,0645
8; 2017-12-07T11:43:43.8166842+01:00; 2017-12-07T11:43:44.8424773+01:00; 1025,7931
11; 2017-12-07T11:43:43.9990189+01:00; 2017-12-07T11:43:44.8989094+01:00; 899,8905
10; 2017-12-07T11:43:43.9383692+01:00; 2017-12-07T11:43:44.9553891+01:00; 1017,0199
测试 3：
- 消息数：每分钟 1000 条
- MaxConcurrentCalls: 1000
- 操作：接收和删除消息
- 预取计数：1000
- 开始平均。 1-2 秒（热身时间明显缩短）
- 结束平均。约 100 毫秒（注意：峰值最长可达 4.5 秒，峰值显着减少）
- 输出：Pastebin link
示例输出：
11; 2017-12-07T11:54:16.8149682+01:00; 2017-12-07T11:54:17.6029464+01:00; 787,9782
14; 2017-12-07T11:54:16.9967915+01:00; 2017-12-07T11:54:17.6709669+01:00; 674,1754
0; 2017-12-07T11:54:16.0599312+01:00; 2017-12-07T11:54:17.6720080+01:00; 1612,0768
15; 2017-12-07T11:54:17.0578415+01:00; 2017-12-07T11:54:17.6724941+01:00; 614,6526
===========================
客户：
using System;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Azure.ServiceBus;
namespace Sticos.ServiceBus.Client
{
public class ServiceBusClient
{
private readonly string _connectionstring;
private readonly string _topic;
private readonly TopicClient _topicClient;
public ServiceBusClient(string connectionstring, string topic)
{
_connectionstring = connectionstring ?? throw new ArgumentNullException(nameof(connectionstring));
_topic = topic ?? throw new ArgumentNullException(nameof(topic));
_topicClient = new TopicClient(_connectionstring, _topic);
}
public async Task SendAsync(string message)
{
await _topicClient.SendAsync(
new Message()
{
Body = Encoding.UTF8.GetBytes(message + ";" + DateTime.Now.ToString())
});
}
}
}
制作人：
using System;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace Sticos.ServiceBus.Client.Test
{
[TestClass]
public class ServiceBusClientTest
{
[TestMethod]
public void Producer()
{
var serviceBus = new ServiceBusClient("[connectionstring]", "[topic]");
var producer = Task.Factory.StartNew(() =>
{
var tasks = new Task[1000];
for (int i = 0; i < 1000; i++)
{
tasks[i] = serviceBus.SendAsync($"{i};{DateTime.Now.ToString("o")}");
Thread.Sleep(60);
}
Task.WaitAll(tasks);
});
Task.WaitAll(producer);
}
}
}
【问题讨论】：
-
我不能不注意到您正在使用同一个客户端来处理所有 1000 条消息。这意味着使用单个连接来推送所有这些消息。一个连接有一个特定的点，它不会发送比它所能发送的更多（就像管道一样）。一种解决方案是拥有从多个工厂创建的多个客户端。当您只有一个连接时，将并发数提高到 100 似乎并不明智。
-
问题不在于发送的消息数量。这是从生产者 (PC#2) 向消费者 (PC#1) 发送一条消息的时间。服务总线每分钟处理 10 000 条消息的负载就好了。每条消息到达目的地的时间平均为 100-200 毫秒。我们希望这个时间更短。
标签： azureservicebus azure-servicebus-topics