PernixData FVP Hit Rate Explained

I assume most of you know that PernixData FVP provides a clustered solution to accelerate read and write I/O. In light of this I have received several questions around what the “Hit Rate” signifies in our UI. Since we commit every “write” to server-side flash then you obviously are going to have a 100% hit rate. This is one reason why I refrain calling our software a write caching solution!

However the hit rate graph in PernixData FVP as seen below is only referencing the read hit rate. In other words, every time we can reference a block of data on the server-side flash device it’s deemed a hit. If a read request cannot be acknowledged from the local flash device then it will need to be retrieved from the storage array. If a block needs to be retrieved from storage then it will not be registered in the hit rate graph. We do however copy that request into flash, so the next time that block of data is requested then it would then be seen as a hit.

Keep in mind that a low hit rate, doesn’t necessarily mean that you are not getting a performance increase. For example if you have a workload in “Write Back” mode and you have low hit rate, then this could mean that the workload has a heavy write I/O profile. So, even though you may have a low hit rate, all writes are still being accelerated because all the writes are served from the local flash device. 

Basic Primer: IOPS

If you are a Virtualization Admin then you most likely have had to get your feet wet when it came to learning the ever-expanding storage market. As the virtualization market has grown so has the amount of storage in the datacenter. This has put a renewed focus on understanding how storage operates in a virtualized cluster. 

In the past Memory and CPU has been something that most have gravitated toward when performance problems arose. While the ticking time bomb in the growth of the virtualized datacenter has been storage performance.

The goal of this post is to give a snapshot understanding why IOPs are one important metric to evaluate when looking at storage performance.

I’m not going to get into the detailed performance characteristics, as that’s not my intent of this post.

Basic Primer:

  • IOPS means: input/output operations per second (A way to measure storage performance on a disk, SAN, SSD, etc.)
  • As a general rule the higher IOPS the better or faster the storage is operating at.
  • The closer a disk is to CPU/Memory the faster the processing time. Network latency can be a huge factor in performance.
  • IOPs are not the only performance metric to look at: Throughput, and Latency is also very important and can affect performance. Best scenario is high IOPs, low latency and high throughput. 

One can classify the input or output operation as a chunk of data that needs to be written or read from disk. As an example, suppose an Exchange database needs to retrieve a list of mailbox objects (Get-MailboxDatabase). This transaction/workload requires information to be accessed from the disk/vmdk in the form of a set amount of inputs and outputs, which the CPU/Memory of the host system will process. How fast this happens is dependent on many things, but it can be measured through the number operations per second it takes for acknowledgement to the application.

This simple example hopefully gave you a better understanding of I/O and why it can be an area easily over looked in regards to application performance.

 If you would like to do a deep dive in understanding storage performance metrics, there is no need for me to recreate the wheel, as others have done an awesome job at telling this part of the story. 

http://www.petri.co.il/avoid-stroage-io-bottlenecks.htm

http://vmtoday.com/2009/12/storage-basics-part-ii-iops/

http://www.symantec.com/connect/articles/getting-hang-iops

http://storageioblog.com