Question

我们正在检查Azure Service总线，将其用作我们的本地服务总线。我们正在测试往返时间，它似乎在10毫秒到2000毫秒之间波动。平均约为100-200ms。似乎有一个预热时间从2秒开始，并在高负荷时下降到200ms。

有没有办法让平均往返时间更短？

使用高级层有帮助吗？ - ＆GT; （编辑：没有帮助。有1个消息单元，平均值实际上更糟糕的是高级层）

我们的设置：

消费者（PC＃1）
制片人（PC＃2）（注意：这两台电脑在同一本地网络上）
Azure Service Bus（实际上是azure）
旁注/有趣的事实：距微软数据中心1500公里。光速使用~10ms往返。

测试1：

消息计数：1000分钟
MaxConcurrentCalls：1
操作：接收和删除消息
预取计数：0
开始平均1-2S
结束平均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-2S
结束平均100-200ms（注意：尖峰长达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-2s（热身显着减少）
结束平均〜100ms（注意：峰值最多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);
        }
    }
}

Answer 1

高级服务总线提供一致的性能，因为您的命名空间将拥有不受嘈杂邻居干扰的专用资源。在标准层上，性能会根据服务的总体负载而波动，因为您的队列/主题与其他客户的队列/主题共享资源。

来自生产者的消息到达消费者所花费的时间，我可以告诉你，服务总线中没有延迟或其他设置引入延迟。服务总线尽可能快地传递消息。我无法真正谈论或帮助提高网络传输速度。

但我认为提高接收消息的吞吐量也会降低消息到达消费者的平均时间。顺便说一下，你没有在这里粘贴代码给消费者。我建议您尝试一些改进。批量发送确实有助于提高性能。不是每个发送呼叫发送一个消息，而是根据消息大小分批发送10或100。如果PEEKLOCK / COMPLETE模式对您不重要，也可以在接收器上尝试使用RECEIVEANDDELETE模式。使用太多并发调用意味着使用太多线程。尝试调整最大并发调用和预取计数值，并查看吞吐量的变化情况。

此外，AMQP提供的性能优于NetMessaging或Http。检查客户端配置以了解正在使用的协议，并将其更改为AMQP。

正如其他答案所暗示的那样，更多连接肯定会提高吞吐量。只需使用更多发件人和更多接收者。

Answer 2

因此，如果您从内部使用Service Bus，则可以执行一些操作。例如，您可以部署到最靠近您自己的数据中心的Azure区域。您可以检查从DC到Azure DC的往返时间并进行延迟测量。您可以评估的另一件事是使用快速路由来最小化延迟。你介意打开支持请求吗？我们可以查看后端，看看我们是否可以在这种情况下进一步帮助您。

Azure Service Bus - 降低往返时间

2 个答案: