When you export a VM (eg for backup purpose) in XenServer, you can use (or not) the built-in compression of the XAPI.
In the coming 4.9 version of Xen Orchestra, you can select "Disable compression" for your XenServer scheduled backups:
Let's try to compare a backup with and without compression activated, on the same VM.
- 25 MB/s throughput to the NFS share
- time: 1m50
- 2.1 GB file
- 8 MB/s speed to the NFS share
- time: 2m13
- 0,5 GB file
The graph recap the VM export (host stats):
That's pretty clear, first test (w/o compression):
- more bandwidth used
- less CPUs
- higher load average (waiting for the storage because of the high throughput)
On the network graph, you could see the difference: the lighest line is the link toward the NFS (write speed). Without compression, the NFS write speed is the bottleneck.
With the compression, the bottleneck is the compression speed of the XenServer host.
Conclusion: with our limited write speed on our NFS repo, compression is the best choice: 30% longer, but only 25% of the uncompressed file size.
If your storage can sustain much higher throughput, the answer could be really different.
Do you a small backup storage and you have time to backup? Compress.
If your NFS target is fast and support deduplication, avoid compression (dedup can't work on compressed XVAs).