0

I'm having a wierd performance problem with the DotNetZip library.

In the application (which runs under asp.net) i'm reading a set of files from the database and packs them on-the-fly into a zip file for the user to download.

Everything works fine on my development laptop. A zip file being about 10MB with default compression rate takes something around 5 seconds to finish. However, on the dev server at the customer, the same set of files takes around 1-2 minutes to compress. I've even experienced even longer times, up to several minutes. The CPU utilization is 100% when the zipping is running, but otherwise it stays around 0%, so it's not due to overload.

What's even more interesting is that on the production server, it takes something about 20 seconds to finish.

Where should I start looking?

Some hardware specs:

My Laptop

Development environment running on a virtualbox with 2 cores and 4GB RAM dedicated.

  • Core i5 M540 2,5GHz
  • 8 GB RAM
  • Win7

Dev Server

According to properties dialog on My Computer (probably virtualized)

  • Intel Xeon 5160 3GHz
  • 540MB RAM
  • Windows 2003 Server

Task Manager Reports Single Core

Production Server

According to properties dialog on My Computer (probably virtualized)

  • Xenon 5160 3GHz
  • 512MB RAM
  • Windows 2003 Server

Task Manager Reports Dual Core

Update The servers are running on a VMWare host. Found the VMWare icon hiding in the taskbar.

Jeff Hammond
  • 5,374
  • 3
  • 28
  • 45
Anttu
  • 1,076
  • 1
  • 10
  • 21
  • both servers are running virus scanners, which also my laptop does. – Anttu Oct 13 '11 at 06:58
  • **different** virus scaner? :-) Other options: non-local files on server (the files aren't really on the server, they are *accessible* from the server and they are in the LAN) – xanatos Oct 13 '11 at 07:12
  • How many files are there? 10? 100? 1000? 10,000? 1,000,000? – xanatos Oct 13 '11 at 07:13
  • Less than 100 files. In the test package about 60. Btw, realizing now that on the dev server the same package contains about 20 files and is half the size... – Anttu Oct 13 '11 at 07:23
  • try to use https://msdn.microsoft.com/en-us/library/system.io.compression.zipfile(v=vs.110).aspx for .NET 4.5+ – juFo Nov 15 '16 at 09:14

2 Answers2

0

as mitch said, the virus scanner would probably be your best bet. that combined with the dev server being just a single core machine and the production server being a dual core (and probably without virus scanner) may explain a delay. what would also be valuable to know is the type of disk in those machines. if the production server and your laptop have SSDs and the dev server has a very old standard harddisk with low rpm, for example, that would also explain a delay. try getting a view on the I/O reads/writes for the zipfolder for the dev server and production server, you could use the SysInternals tools for that, and if you have a virus scanner or any other unexpected process running you're probably going to see a difference there. the SysInternals tools could be of value here in finding the culprit quickly.

UPDATE: because you commented the zip is created in-memory I'd like to add you can also use those tools to get a better understanding of what happens in memory. a delay of several minutes where you'd expect almost equal results because the dev server and production server are a lot alike has me thinking of the page file.. see if there are other processes on the dev server that have claimed a lot of memory. if there isn't enough left for the zip operation the dev server will start using the page file, which is very expensive.

mtijn
  • 3,610
  • 2
  • 33
  • 55
  • The zip file is created in memory, so it should be independent of hard drive type. – Anttu Oct 13 '11 at 06:58
  • As you can see in the hardware specs, the dev server has for some reason a bit more memory dedicated. Task manager also shows (in the PF graph) that the dev server has committed about 550MB and the production server about 1,2GB of memory. The amount is not increasing more than a few MBs when zipping the files. – Anttu Oct 13 '11 at 07:26
0

The hardware seemed to be the problem here.

The customer's IT guys have now upgraded the server hardware on which the virtualized dev server runs and I now see compression times at about 6s for the same package size and number of files as on my local computer.

The specs now found in the My Computer properties window:

  • AMD Phenom II X6 1100T
  • 3.83GHz 1,99 GB RAM
Anttu
  • 1,076
  • 1
  • 10
  • 21