GZipStream解压缩性能差 [英] GZipStream decompression performance is poor

问题描述

我有一个连接到后端的.NET 2.0 WinForms应用程序服务器WAS。我使用GZipStream将数据从向服务器发出一个呼吁的HttpWebRequest回来解码。返回的数据被压缩的CSV，其中Apache是​​压缩。整个服务器堆栈休眠 - > EJB - >春天 - >阿帕奇

I have a .NET 2.0 WinForms app that connects to a backend WAS server. I am using GZipStream to decode data coming back from a HttpWebRequest call made to the server. The data returned is compressed CSV, which Apache is compressing. The entire server stack is Hibernate-->EJB-->Spring-->Apache.

对于小的反应，性能优良。（小于50毫秒）。当我得到回应> 150KB，它需要60秒以上来解压缩。大部分的时间似乎在GZipStream构造函数中度过。

For small responses, the performance is fine (<50ms). When I get a response >150KB, it takes more than 60 seconds to decompress. The majority of the time seems to be spent in the GZipStream constructor.

这是表示我从HttpWebResponse调用的响应流中的代码：

This is the code showing where I get the response stream from the HttpWebResponse call:

using (Stream stream = this.Response.GetResponseStream())
{
 if (this.CompressData && this.Response.ContentEncoding == "gzip")
 {
        // Decompress the response
  byte[] b = Decompress(stream);
  this.ResponseBody = encoding.GetString(b);
    }
 else
 {
  // Just read the stream as a string
  using (StreamReader sr = new StreamReader(stream))
  {
   this.ResponseBody = sr.ReadToEnd();
  }
 }
}

修改1

根据从卢塞罗的评论，我修改了解压的方法下面，但我没有看到加载ResponseStream到前一个MemoryStream任何性能优势实例化GZipStream。

Based on the comment from Lucero, I modified the Decompress method to the following, but I do not see any performance benefit from loading the ResponseStream into a MemoryStream before instantiating the GZipStream.

private static byte[] Decompress(Stream stream)
{
 using (MemoryStream ms = new MemoryStream())
 {
  byte[] buffer = new byte[4096];
  int read = 0;

  while ((read = stream.Read(buffer, 0, buffer.Length)) > 0)
  {
   ms.Write(buffer, 0, read);
  }

  ms.Seek(0, SeekOrigin.Begin);

  using (GZipStream gzipStream = new GZipStream(ms, CompressionMode.Decompress, false))
  {
   read = 0;
   buffer = new byte[4096];

   using (MemoryStream output = new MemoryStream())
   {
    while ((read = gzipStream.Read(buffer, 0, buffer.Length)) > 0)
    {
     output.Write(buffer, 0, read);
    }

    return output.ToArray();
   }
  }
 }
}

根据在上面的代码，任何人都可以看到任何问题？这似乎是很基本的我，但它的驾驶我坚果。

Based on the code above, can anyone see any issues? This seems quite basic to me, but it's driving me nuts.

编辑2

我异形用蚂蚁探查应用程序，解压60年代期间，CPU是接近零，内存使用量不发生变化。

I profiled the application using ANTS Profiler, and during the 60s of decompression, the CPU is near zero and the memory usage does not change.

修改3

实际的放缓似乎是

this.Response.GetResponseStream

整个60年代期间读花在加载响应流进的MemoryStream。一旦它的存在，调用GZipStream快。


修改4

The entire 60s is spent loading the response stream into the MemoryStream. Once it's there, the call to GZipStream is quick.
Edit 4

我发现，使用HttpWebRequest.AutomaticDecompression表现出相同的性能问题，所以我关闭了这个问题。

I found that using HttpWebRequest.AutomaticDecompression exhibits the same performance issue, so I'm closing this question.

推荐答案

首先尝试将数据加载到一个MemoryStream，然后解压缩的MemoryStream ...

Try first loading the data into a MemoryStream and then decompress the MemoryStream...

这篇关于GZipStream解压缩性能差的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！