Site icon Franky's Web

Exchange 2016: Testing storage performance with Jetstress (comparison of NTFS to ReFS) Part 2

In first part of this series I had already started to analyze the difference between ReFS and NTFS in connection with Exchange 2016. However, the test environment was not yet optimized, but now it looks a little different.

As a reminder: a VM on vSphere 5.5, Windows Server 2012 R2, 8 vCPUs (Xeon E5-2690v3), 32 GB RAM serves as the basis. The VM was retained, but slightly optimized: Databases and log files are now located on different volumes, each formatted with either NTFS or ReFS. The VM now has a total of 3 virtual SCSI controllers (operating system SCSI1, databases SCSI2 and logs SCSI3). On the storage side, however, all volumes are stored on the same LUN for better comparison. The VMDKs were created Thick Eager Zeroed. No further fine-tuning has been carried out.

Jetstress ran again for 2 hours, but this time with separate databases and log files:

To cut a long story short, here is a direct comparison between NTFS and ReFS from a storage perspective:

Over 1000 IOPS less with ReFS, that's quite a house number,

30 MB/s less throughput. Here from the ESX's point of view:

scsi1:0 and scsi2:0 are the databases, so here it is clear that most of the IO load is produced on the database, not on the log files (scsi3:0, scsi3:1). And this is what the whole thing looks like within the VM:

In principle, the same values for CPU and RAM utilization. Here is the Jetstress evaluation:

NTFS

ReFS

Die Messwerte sind schon mal deutlich besser, besser im Sinne von „ausschlaggebender“. Beim Ersten Test, waren die Werte „etwas“ irreführend. Damit die Werte besser vergleichbar sind, habe ich ReFS und NTFS mal direkt unter einander geschrieben:

Preliminary conclusion:

NTFS beats ReFS. At this point there is still no feature comparison between ReFS and NTFS, but in terms of performance NTFS seems to have the edge here, lower latencies, higher throughput, more operations per second.

But this is only the preliminary conclusion, there are always a few adjustments that can be made... More to follow...

Exit mobile version