我们在使用Azure Service Bus Relay的netTcpRelayBinding和basicHttpRelayBinding时存在速度问题。在消息大小较小(10K)时,中继操作具有较低的延迟(100毫秒),但随着消息大小的增加(100K),我们遇到了看似随机的响应时间(600ms-1000ms)。我们希望改善较大消息的延迟成本。
使用消息压缩(例如gzip、protobuf-net等)是否支持通过Service Bus中继?有人成功启用了请求/响应压缩吗?支持响应压缩通过IIS非常容易,但我们想支持请求压缩以改善延迟成本。由于我们无法使用Fiddler对中继进行分析,我们如何知道消息在通过中继时仍然被压缩?
我们发现一个有趣的点是,在连续的信息传递之间引入延迟(2秒),我们可以获得更好的性能(100K-200ms)。可能较大的消息正在自动限制吗?知道触发限制条件的消息大小截止值将是很好的了解。
对于我们的测试-我们只是向服务中继发送一个随机消息字符串,并从服务器回显请求字符串。我们已经尝试从多个地理位置使用此客户端/服务器(排除防火墙/ Web过滤器问题),并且遇到了相同的延迟行为。
使用消息压缩(例如gzip、protobuf-net等)是否支持通过Service Bus中继?有人成功启用了请求/响应压缩吗?支持响应压缩通过IIS非常容易,但我们想支持请求压缩以改善延迟成本。由于我们无法使用Fiddler对中继进行分析,我们如何知道消息在通过中继时仍然被压缩?
我们发现一个有趣的点是,在连续的信息传递之间引入延迟(2秒),我们可以获得更好的性能(100K-200ms)。可能较大的消息正在自动限制吗?知道触发限制条件的消息大小截止值将是很好的了解。
对于我们的测试-我们只是向服务中继发送一个随机消息字符串,并从服务器回显请求字符串。我们已经尝试从多个地理位置使用此客户端/服务器(排除防火墙/ Web过滤器问题),并且遇到了相同的延迟行为。
服务器端
public class ServiceRelayProfiler : IServiceRelayProfiler
{
public string HelloProfiler(string name)
{
return string.Format("Hello {0}", name);
}
}
客户端
ChannelFactory<IServiceRelayProfiler> channelFactory = new ChannelFactory<IServiceRelayProfiler>("helloProfilerTcp");
IServiceRelayProfiler channel = channelFactory.CreateChannel();
string message = RandomString(100000); // 100K
for (int i = 0; i < 100; i++)
{
DateTime start = DateTime.Now;
string response = channel.HelloProfiler(message);
DateTime end = DateTime.Now;
TimeSpan duration = end - start;
Console.WriteLine("Response is: {0} at {1}\tDuration: {2}ms", response.Substring(0, 20) + "....", end, duration.Milliseconds);
//Thread.Sleep(2000); // delay makes response times more consistent
}