Real World Domain Controller on FVP


Continuing the series of posts on real world acceleration of enterprise applications this post demonstrates results of accelerating a Windows 2008 R2 Domain Controller in a mid-size enterprise.

A quick refresher on the environment:

  • 8 node ESXi 5.0 Update 2 cluster with Dell M620 blade servers
  • 10 Gb networking
  • FC storage connectivity
  • Back-end array with about 250 spindles (a combination of FC, SAS, and SATA disks) able to deliver approximately 35,000 - 40,000 IOPS.
  • PernixData FVP installed with a 400 GB Intel S3700 SSD drive in each host.
  • A little under 200 VMs accelerated with write-back (WB) + two peers for redundancy.

The server names have been changed to provide a description of the primary application running on them.

Domain Controller 1

Description: Windows 2008R2 Domain Controller, AD-integrated DNS Server, one of ten DCs in a multi-site, multi-forest AD.


The graph below shows how datastore latency from the backing array to the VM between around 3 ms (very good) and 10 ms, with spikes over 10 ms and even over about 28 ms within a 1 hour window. Local flash latency however is consistently around 0.5 ms with effective latency to the VM around 2 ms or less with the occasional spike, including write replication to 2 peers. At the time of the first large spike to around 28 ms the effective latency to the VM is about 1/3rd that and where the second spike is around 27 ms from the datastore the effective latency to the VM is 2 ms or less, or about 13x lower.

Domain Controller 1 Latency DS 1 Hr

Domain Controller 1 Latency DS 1 Hr

Hit Rate:

The read cache hit rate during the pictured time frame below varies wildly. As a primary DC in a mid-size enterprise with several thousand accounts and over 100 applications there is lot of AD authentication by users and service accounts, many LDAP queries, and a large number of writes to AD occurring constantly. As you can see in the graph above the datastore latency on the array varies a lot and offloading only reads would still subject the VMs and applications to the latency shown by the purple line. In fact the latency experienced by the VM if only reads were being accelerated would be worse as the purple line is showing datastore latency after reads and writes are being serviced through SSD drives in hosts. So the purple line actually reflects the smoothing out of latency fluctuations on the array since local flash is absorbing the spikes, and would otherwise show higher latency values.

Domain Controller 1 Hit Rate 1 Hr

Domain Controller 1 Hit Rate 1 Hr


As you can see the storage performance improvements to the domain controller are significant. In this short window alone storage latency is often improved 5x or more and at times over 10x better than what is provided by the back-end array. AD latency can affect all applications on networks where AD authentication is used, and lower values often translate to more responsive applications and happier users.

Not shown on these graphs is that improvements are even more pronounced at times of the day when large groups of users log onto the network and are active within applications, and during nightly backups when array latencies spike much higher and much more frequently. Reducing latency after hours is sometimes overlooked but is very important to:

  • increase backup speeds for both accelerated and non-accelerated workloads (since hot data is in cache and the array is not as busy as it would otherwise be)
  • improve the user experience for off-shore employees who come online during the backup window, for night-shift workers, and for sysadmins working after hours
  • reduce the time it takes for nightly batch jobs to complete
  • improve the experience for NOC operators who cover shifts 24 hours a day

Your mileage will vary depending on your workloads, but I hope that you find use in these graphs which show a snapshot of the improvement seen on a domain controller in a real world deployment of PernixData FVP in a mid-size enterprise.

Website Security Test