Azure Service Bus Relay - 启用压缩

Question

我们在使用有速度问题Azure的服务总线中继既netTcpRelayBinding和basicHttpRelayBinding.对于小消息大小(10K),中继以低延迟(100ms)运行,但随着消息大小增加(100K),我们经历看似随机的响应时间(600ms-1000ms).我们希望改善较大邮件的延迟成本.

是否正在使用通过服务总线中继支持的消息压缩(gzip,protobuf-net等)？有没有人通过中继启用请求/响应压缩成功？通过IIS支持响应压缩是微不足道的,但我们希望支持请求压缩以提高延迟成本.由于我们无法用Fiddler来描述中继,我们如何知道消息在通过中继时仍然被压缩？

---

我们发现一个有趣的观点是,在后续消息中继(2s)之间引入延迟,我们可以获得更好的性能(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
}

Answer 1

这不是完整的答案，但在服务器端，您可以将其添加到global.asax.cs允许请求解压缩：

public class MvcApplication : System.Web.HttpApplication
{    
    protected void Application_BeginRequest(Object sender, EventArgs e)
    {
        //Activate request decompression
        string contentEncoding = Request.Headers["Content-Encoding"];
        if (contentEncoding != null && contentEncoding.Equals("gzip", StringComparison.CurrentCultureIgnoreCase))
        {
            Request.Filter = new GZipStream(Request.Filter, CompressionMode.Decompress, true);
        }
    }
}