FancyCache Benchmark with Iometer (2) Read

Read Performance Testing

Testing Preparations

Testing Items:
   Transfer Size (bytes): 1M, 512K, 256K, 128K, 64K, 32K, 16K, 8K, 4K, 2K, 1K, 512
   100% Read
   100% Random & 100% Sequential
   32 Outstanding IOs & 1 Outstanding IO

Other Iometer Specifications:
   Run time: 5 minutes per item
   No I/O alignment (Align IOs on Sector Boundaries)

Sequence of Testing Items in One Batch Run:
   1MB 100% random
   512KB 100% random
   ...
   512B 100% random
   1MB 100% sequential
   512KB 100% sequential
   ...
   512B 100% sequential

Total time in one batch run: 24 * 5 Minutes = 2 Hours

Secure-erase drive after batch run testing to ensure performance consistency. (Specific to Solid-State Drives)

FancyCache Settings:
   Block Size: 4KB & 16KB
   Cache Size: 1024MB
   Algorithm: LFU-R
   Caching Strategy: Read/Write
   Defer-Write: off
   L2 Caching: off

Testing Results

Scenario #1: Full range testing, covering the whole drive (drive size 40GB >> 1GB Cache Size)

Scenario #2: limited range testing, less than cache size
(Specify Maximum Disk Size in Iometer: 2,000,000 Sectors, ~976MB < 1024MB Cache Size)

FC050(4KB): FancyCache 0.5.0, Block Size: 4KB
FC050(16KB): FancyCache 0.5.0, Block Size: 16KB

Comments

1. In scenario #1, Iometer writes a large test file (about 40GB) which covers the whole drive when preparing the testing, leading to the full comsumption of the cache. This is the worst case and the read hit rate is very low, almost 0. In scenario #2, the whole test file prepared by Iometer is about 976MB which less than cache size. All testing data can be hold in cache. This is the best case and can reach the 100% hit rate. The performance is surprisingly great in this scenario.

2. To get the best read performance, it is recommended that the Block Size of FancyCache is set to be equal to or less than the cluster size of the file system. This rule applies to 1) FancyCache Volume Edition, 2) FancyCache Disk Edition if the drive is SSD and was partitioned under Win7.
(Note: Although the performance can be improved by matching block size with cluster size, it might lead to the large additional memory allocated if the block size is too small, especially when the targe volume/drive is in large capacity.)