Les performances de la décompression GZipStream sont médiocres

Question

J'ai une application .NET 2.0 WinForms qui se connecte à un serveur WAS backend. J'utilise GZipStream pour décoder les données provenant d'un appel HttpWebRequest fait au serveur. Les données renvoyées sont CSV compressé, compressé par Apache. La pile entière du serveur est Hibernate -> EJB -> Spring -> Apache.

Pour les petites réponses, les performances sont bonnes (< 50ms). Quand je reçois une réponse> 150 Ko, il faut plus de 60 secondes pour décompresser. La majorité du temps semble être passé dans le constructeur GZipStream.

Ce code montre l'endroit où je reçois le flux de réponse de l'appel HttpWebResponse:

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(); 
    } 
} 
} 

Modifier 1

Basé sur le commentaire de Lucero, j'ai modifié la méthode Décompresser à ce qui suit , mais je ne vois aucun avantage de performance de charger le ResponseStream dans un MemoryStream avant d'instancier le 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(); 
    } 
    } 
} 
} 

Basé sur le code ci-dessus, quelqu'un peut-il voir des problèmes? Cela me semble assez basique, mais ça me rend fou.

Edit 2

I profilées l'application en utilisant ANTS Profiler, et dans les années 60 de décompression, l'unité centrale est proche de zéro et l'utilisation de la mémoire ne change pas.

Edit 3

Le ralentissement actuel semble être au cours de la lecture de

this.Response.GetResponseStream

Les années 60 entièrement passé le chargement du flux de réponse dans le MemoryStream. Une fois qu'il est là, l'appel à GZipStream est rapide.
Modifier 4

Je trouve que l'utilisation HttpWebRequest.AutomaticDecompression présente le même problème de performance, donc je ferme cette question.

Answer 1

Essayez d'abord charger les données dans un MemoryStream puis décompressez le MemoryStream ...

Answer 2

Désolé de ne pas répondre directement à votre question, mais avez-vous regardé SharpZip encore? Je l'ai trouvé beaucoup plus facile à utiliser que Gzip. Si vous avez de la difficulté à résoudre votre problème actuel, peut-être que cela faciliterait la tâche.

http://www.icsharpcode.net/OpenSource/SharpZipLib/

Answer 3

DotNetZip a une classe GZipStream qui peut être utilisé comme une solution de remplacement pour le System.IO.Compression.GZipStream.

DotNetZip est gratuit. NB: Si vous ne faites que GZipStream, alors vous avez besoin de l'Ionic.Zlib.dll, pas de l'Ionic.Zip.dll.

Answer 4

Je vais laisser tomber mes trois cents sur le sujet, juste pour avertir les utilisateurs C# qu'un 7Zip semble exposer son API en langage C#.Je pense que vous connaissez tous très bien l'outil 7Zip, et au moins pour moi, quelle que soit la qualité de son API, sachant que cela aide énormément à améliorer la gestion des fichiers/flux ZIP.

ref: http://www.splinter.com.au/compressing-using-the-7zip-lzma-algorithm-in/