c# - Azure服务总线中继-启用压缩

在同时使用netTcpRelayBinding和basicHttpRelayBinding的 Azure服务总线中继时，我们遇到速度问题。在消息大小较小(10K)的情况下，中继以低延迟(100ms)运行，但是随着消息大小增加(100K)，我们会遇到看似随机的响应时间(600ms-1000ms)。我们希望提高大型邮件的延迟成本。

通过服务总线中继是否支持使用消息压缩(gzip，protobuf-net等)？是否有人成功通过中继启用请求/响应压缩？它是trivial to support response compression through 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
}

最佳答案

这不是一个完整的答案，但是在服务器端，您可以将其添加到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);
        }
    }
}