There is alot of talk about ZFS compression being “faster” than a non-compressed pool due to less physical data being pulled off the drives. This of course depends on the system powering ZFS, but i wanted to run some tests specifically on latency. Throughput is fine in some situations, but latency is a killer when it comes to lots of small reads and writes (in the case of hosting virtual machines)

I recently completed some basic tests focusing on the differences in latency when ZFS compression (lzjb) is enabled or disabled. IOMeter was my tool of choice and i hit my ZFS box via a mapped drive.

I’m not concerned with the actual figures, but the difference between the figures

I have run the test multiple times (to eliminate caching as a factor) and can validate that compression (on my system anyhow) increases latency

Basic Results from a “All in one” test suite… (similar results across all my tests)

ZFS uncompressed:

IOps : 2376.68
Read MBps : 15.14
Write MBps : 15.36
Average Response Time : 0.42
Average Read Response Time : 0.42
Average Write Response Time : 0.43
Average Transaction Time : 0.42

ZFS compressed: (lzjb)

IOps : 1901.82
Read MBps : 12.09
Write MBps : 12.28
Average Response Time : 0.53
Average Read Response Time : 0.44
Average Write Response Time : 0.61
Average Transaction Time : 0.53

As you can see from the results, the AWRT especially is much higher due to compression. I wouldn’t recommend using zfs compression where latency is a large factor (virtual machines)

Note: Under all the tests performed the CPU (dual core) on the zfs box was never 100% – eliminating that as a bottleneck.

Related posts:

1. iometer testing The following is some notes i have around the parameters...
2. vMA – Using HP Power Protector agent to shutdown virtual hosts Goal was to create a vMA which would send a...
3. vmware – measuring iscsi write performance I picked this trick up off vmware support. If you’ve...

Related posts brought to you by Yet Another Related Posts Plugin.

lzjb (default) | gzip | gzip-[1-9]

They are used via the zfs set compression=gzip poolname command.

The following test was quickly done out of personal interest – and is in no way scientific!

I have a AMD cpu with 3 cores (2.4Ghz). The data i copied to each of the shares consisted of video / documents / pictures and music. The first test i have done is based on compression only (i have not measured throughput)

Original Data Size : 412MB

lzjb : 312MB Compression ratio : 1.32

gzip : 293MB Compression ratio : 1.41

gzip9 : 292MB Compression ratio : 1.41

gzip is the winner on compression. With this small sample of data it is unclear if the extra CPU overhead on a gzip-9 zfs files system is worth it – from these results i would say it isn’t.

Again – gzip may be the winner on compression, but this does not reflect an improvement on throughput (untested).

Update: i’ve done a quick test on cpu load and throughput and i wouldnt recommend using gzip unless you are really limited on disk space – or have plenty of CPU to spare. lzjb is much faster (less load on cpu) and does a pretty good job for compression on the fly.

Related posts:

1. zfs compression and latency Since im using ZFS as storage via NFS for my...

Related posts brought to you by Yet Another Related Posts Plugin.