[
  {
    "Id": "444463",
    "ThreadId": "213063",
    "Html": "<p>Hi,</p>\r\n<p>I developed a web application which zips files using DotNetZip. Everything works as expected on my local dev machine and performance is good. When I deploy to a test environment however, performance seems to be pretty bad. I have nailed down the line that takes some time.</p>\r\n<p>It's where I try to save the zipfile to a memorystream</p>\r\n<p>zipFile.Save(ms);</p>\r\n<p>This sometimes takes 90 (wow)&nbsp;seconds, sometimes 2 seconds and sometimes 15 seconds. It's very random, even with the same set of files that are being zipped I am only zipping&nbsp;2 relatively small files (~1mb each); a pdf file and a&nbsp;doc file.</p>\r\n<p>I was wondering if my test environment is simply unstable, or whether you could think of anything that could cause this behaviour? It's literally just the call to zipFile.Save(ms) that is slow.</p>\r\n<p>Thanks,</p>\r\n<p>Jaap</p>\r\n<p>&nbsp;</p>\r\n<p>&nbsp;</p>\r\n<p>&nbsp;</p>\r\n<p>&nbsp;</p>",
    "PostedDate": "2010-05-18T10:48:46.887-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  },
  {
    "Id": "444529",
    "ThreadId": "213063",
    "Html": "<p>I have no good ideas. MemoryStream is an auto-expanding stream, so it may be having some problems re-allocating buffers as it expands.</p>\r\n<p>Maybe you could describe more your design and why you're putting things into a memory stream.&nbsp; How large is the zip file anyway?</p>\r\n<p>Generally you don't want to retain the zip file in a memory stream.&nbsp; You want to write it to the disk, or send it in the response stream.&nbsp; Putting it all in the memory stream would be sort of unusual.</p>\r\n<p>It could be that if you are sending the zip as a response, eliminating the memory stream would increase performance significantly.</p>",
    "PostedDate": "2010-05-18T12:59:43.983-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  },
  {
    "Id": "444547",
    "ThreadId": "213063",
    "Html": "<p>Thanks for replying Cheeso.</p>\r\n<p>I am calling another API (which I don't own) which ultimately stores the zip file in a database (which I am not allowed to touch directly). This API call requires me to pass in a byte array. I am&nbsp;writing&nbsp;to the MemoryStream so I can easily get the bytes from it so I can pass them to the API call.</p>\r\n<p>I am just a bit confused around the fact that it only behaves this poorly on my test environment, and the numbers seems to random (90 secs, 2 secs, 15 secs, etc) even tough I am zipping the same files. I will do some more investigation work&nbsp;tomorrow.</p>",
    "PostedDate": "2010-05-18T13:38:31.037-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  },
  {
    "Id": "444646",
    "ThreadId": "213063",
    "Html": "<p>ok well if you need the byte array then saving to a memory stream is probably the right thing. <br>There's one semi-exotic thing that happens during a save. If the thing to be saved is above a certain threshold, then DotNetZip will create multiple threads to do the compression.&nbsp; See <a href=\"http://cheeso.members.winisp.net/DotNetZipHelp/html/dd2291bf-1c5a-8f1b-cfa6-34239e73ad13.htm\">the documentation for the ParallelDeflateThreshold property</a>.&nbsp;</p>\r\n<p>If your ASPNET system is thread-constrained, that may cause a surprising latency during the save.&nbsp; To check if threading is the problem you can set ParallelDeflateThreshold to -1, which tells DotNetZip to never use separate threads.&nbsp; If you see the same odd variation in performance, then ... it's not the threading.</p>\r\n<p>&nbsp;</p>",
    "PostedDate": "2010-05-18T18:32:54.357-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  },
  {
    "Id": "444766",
    "ThreadId": "213063",
    "Html": "<p>Awesome, that fixed it!</p>\r\n<p>Every call to zipFile.Save(ms) is now consistently around 0.5 secs, which I am extremely happy with.</p>\r\n<p>Thanks -&nbsp;you're the man! :)</p>",
    "PostedDate": "2010-05-19T02:15:11.457-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  }
]