Search the Community
Showing results for tags 'Performance CPU compression'.
Found 1 result
One of my customers asked for an assessment of how to get the best performance out of their backups and still have some security on the backup set and make the best use of storage. They are similar to many of my other customers in that they have a modern multi-core Mac Intel CPU server with 1000T network and eSATA or Fibre Channel attached storage devices. One difference with this customer is that they back up mostly JPG files. I set out to test a variety of scenarios to see how they would perform and where the bottlenecks were. I thought it was worth sharing and may also give the Retrospect developers some information about how Retrospect 9 performs in the real world backing up JPG images. Here are the results and my recommendations to them: -------------- I set up a series of backups of 19,613 files totaling 13.75GB of primarily JPG files which should give similar results on a smaller scale to what the customer has. There were no TIFF files in my batch so compression of those files would result in slightly higher overall compression. I used a 2010 Mac Pro 2.93 GHz quad-core eSATA connected to a Western Digital My Book Studio Pro II 4TB backup drive. The client machine is a MacBook Pro connected via 1000T ethernet with a 7200 RPM 500GB disk drive. For the first test I ran the following settings: Password protection, no compression, no verification, no catalog compression and got the following results: Elapsed time: 6 min 31 secs, Data Rate: 2.1 GB/min, Backup Set size: 13.73 GB Retrospect CPU Usage ~ 100% of 1 CPU almost entire time Workstation CPU ~ 15% of 1 CPU average I then turned on Media Verification and ran it again which produced: Elapsed time: 9 min 20 secs, data rate: 1.5 GB/min, backup set size: 13.73 GB Retrospect CPU Usage ~ 100% of 1 CPU almost entire time I did not test turning on "Thorough Verification". I turned verification back off and turned on compression which produced: Elapsed time: 12 min 42 secs, data rate: 1.5 GB/min, backup set size: 14.62 GB - NOTE LARGER SIZE WITH COMPRESSION Retrospect CPU Usage ~ 100% of 1 CPU almost entire time I believe that the larger size above was the result of Retrospect trying to compress JPG documents which are already highly compressed which results in the compressed file actually being larger than the original. Turning verification back on and keeping compression yielded: Elapsed time: 14 min 18 secs, data rate: 0.894 GB/min, backup set size: 14.62 GB Retrospect CPU Usage ~ 100% of 1 CPU during both backup and verification phases To see how much disk drive bandwidth affects the remote backups I switched from using the eSATA 3Gbps port to FireWire 800 on the same drive and re-ran the uncompressed fastest backup: Elapsed time: 6 min 42 secs, data rate: 2.0 GB/min, backup set size: 13.73 GB This surprised me, I was expecting the eSATA to perform at a much higher rate but the current version of Retrospect is unable to deliver the data fast enough to make use of it. At this point I switched to using AES-128 Encryption and re-ran the relevant tests (using the eSATA interface again) Testing with encryption but no compression yielded: Elapsed time: 11 min 45 secs, data rate: 1.1 GB/min, backup set size: 13.73 GB Retrospect CPU Usage ~ 115% of 1 CPU almost entire time Testing with both encryption and compression yielded Elapsed time: 17 min 40 secs, data rate: 0.76 GB/min, backup set size: 14.62 GB Retrospect CPU Usage ~ 110% of 1 CPU almost entire time Conclusions: 1. Retrospect Server is single-CPU-limited even with uncompressed remote backups. Use the fastest CPU available. 2. Even with a fast 2.93 GHz Xeon CPU Retrospect was barely able to fully saturate FireWire 800 so there is not a lot of benefit to using the faster eSATA interface on a machine below 3GHz. The faster interface yielded only about a 3% speed benefit. 3. Media Verification slows backup of a remote device by about 50% 4. Compression slows backup by about 100% and may result in larger backup files if highly compressed original files are being backed up. 5. Data Encryption appears to be able to make use of at least part of an additional CPU reducing its impact on the backup time. 6. Data Encryption did NOT increase the size of the backup but did incur almost a 50% performance penalty over password protected 7. The combination of Encryption and Compression reduces the speed to only about 1/3 the speed of Password without compression 8. Slowest backup is Encryption, Compression, Verification Recommendation for my customer: 1. Leave compression off, the decreased speed and increased size of already-compressed files makes it not worthwhile for JPG backups 2. Leave catalog compression off 3. Use either "No Verification" or "Media Verification" (but keep "Generate MD5 Digest" option turned on for manual verification) Recommendation to Retrospect team 1. Figure out how to take advantage of multiple CPUs on the server machine 2. Consider distributing the compression and/or encryption workload to the client