Delphix 3.2 Performance
We recently shipped Delphix ver 3.2 (codename Cybertron). In this post, I will talk about some of the performance work we did in that release. At Delphix, we do not wish to rely on superior hardware to deliver performance to our customers. We want customers to realize the benefits of agility even when Delphix is overlaid on existing hardware.
In Cybertron we focused our performance work on reducing the amount of time required for synchronous activities, and on being more intelligent in our use of hardware resources (in particular with slow hardware).
Delphix provides a native service to replicate critical application data from one server to another (more details here).
When customers replicate Delphix Engine to a remote host, they typically send data over a wide area network (WAN). This data stream when compressed, will consume CPU resources instead of network resources. In our previous release, Betelgeuse, we used gzip to compress the data stream.
GZIP is heavy on CPU usage but provides very good compression. In our latest release, we migrated to LZ4 compression, which provides better compression while being much lighter on its use of CPU. In our test environment, we pushed effective replication throughput to 160MB/sec on a 1 GigE link -- well over line speed maximum without compression.
On a slow network, this means around 50% higher throughput with compression enabled. Most of our customers can now enable compression, and achieve higher throughput while reducing the load on their WAN.
Virtual Database (VDB) Agility
Support for VDB NOARCHIVELOG mode
We removed a restriction present in Betelgeuse that all VDBs should run in ARCHIVELOG mode.This reduces the amount of network traffic (writes) generated by a VDB by more than 50%. The savings in network load will improve performance in bandwidth constrained environments. Along with this we also added two features to improve the user perceived time to create a virtual database.
New in 3.2 is the ability to configure an optional staging host to process data offline and accelerate VDB provisioning. Provisioning a VDB involves applying logs -- the more logs there are to apply, the longer the provisioning operation can take. With this feature enabled, part of that log file application is done proactively in the background. This reduces the amount of time required to provision a VDB -- in some cases to nearly nothing!
Delphix completely automates the process of creating new VDBs.
As such it is in complete control of the process, and handles any failure or unexpected condition. In previous releases provisioning executed most of its write operations as synchronous -- blocking until the write reached disk. We observed that while synchronous writes are necessary for consistency and resiliency of normal database operations, we can relax that condition for provisioning. In 3.2 we use exclusively asynchronous writes, accelerating provisioning significantly.
We can do this safely because Delphix manages the provisioning operation and handles any failures. Once provisioning is completed and the VDB has been verified to be correct, I/Os return to their normal, safe behavior.
In 3.2 we made significant investments in DxFS to address specific pain points we have seen at various customers.
Performance gains from these may not be evident in all environments, but we expect to see improvements in many conditions. We redesigned the write throttle mechanism in DxFS to ensure a smooth and consistent stream of IO to the backend SAN. In a situation where the Delphix Engine is forced to take in more IO from the VDBs+Sources than the backend can sustain, the new write throttle mechanism will help produce a steady stream of IO going to the SAN and achieve more consistent latencies for VDBs.
We also laid the groundwork to improve performance of DxFS when the Delphix Engine is low on space. Broader improvements from these projects will come in the Dune release. Please watch this space for more detailed blog posts on several of these features from my colleagues.