Delphix Version 3.0

Last week we released

Last week we released Delphix Version 3.0, which extends Delphix database virtualization technology to Microsoft SQL Server and Oracle Real Application Clusters (RAC). As with previous releases, the newest version of our server includes a number of innovative features, a comprehensive list can be found here. Along with our focus on rolling out new functionality, we continue to invest in boosting the performance of our server. This post is dedicated to highlighting some of the key performance improvements you can expect from Delphix 3.0.

Enhanced Caching

ARC is the Adaptive Replacement Cache, used by DelphixOS to improve latency of reads. Accesses that are satisfied in the ARC are typically an order of magnitude faster compared to traditional storage. Delphix 3.0 features enhanced caching by allowing ARC to be shared between all the Virtual Databases (VDBs) provisioned. This improves utilization of ARC space and reduces average latencies for read only data.

Performance improvements from sharing ARC stem from two major components. First, sharing ARC between all the VDBs improves utilization of ARC space. In Delphix 2.7, every VDB had its own address space. This means, even if two VDBs were reading the same data, they maintained separate copies of it in the ARC. This reduces effective utilization of ARC space. In 3.0, each unique block is allocated in memory only once; if you have 10 VDBs for example, you’re getting 10 times the efficacy out of your memory. Efficient use of memory increases the amount of data that can be cached overall.

The second component of the performance comes from improved latencies. By sharing address space between VDBs, they will start seeing shared cache effects. For example, if you have 10 VDBs, only one of them will have to read its data from disk. The rest of them can read that data much faster from the ARC.

Performance gains from sharing ARC will vary depending on the amount of sharing each VDB is getting from the data (locality of reference) plus the working set of all the VDBs combined in the non-shared scenario. We typically see our customers maxed out on ARC, so this feature is expected to show good performance gains.

In order to showcase the benefits of this feature, I constructed an experiment which is scaled down from a realistic scenario. I am using DelphixBench to run a shared ARC vs. non-shared ARC experiment. Non-Shared ARC mimics the behavior of Delphix 2.7. As you can see, for this scenario, sharing ARC space will produce close to 30% improvement in performance. For this particular workload, the working set size is ~9GB. I provisioned a Delphix virtual appliance with 4GB of memory.  In customer environments, working set size is typically larger than the ARC space available. In this particular experiment, the benefits are coming both from ARC space utilization and prefetching between VDBs resulting in better average latency. Note that improvements from this feature are tightly dependent on customer environments. The more VDBs you have, the more benefit you see, and the more value you get out of each byte of memory you buy.

Faster Virtual Database Provisioning

Provisioning a VDB involves creating a clone of the snapshot from the production database and then applying all the logs since the time snapshot was created -to re-create a consistent in time copy of the production database. The amount of time taken to provision a VDB is independent of the size of the database, but was tightly dependent on the amount of log activity needed to be recovered. Providing fast and consistent provisioning time will improve workflows for customers. With version 3.0 we have alleviated the dependency on redo/log activity to provide better provisioning times.

The chart below shows the absolute time taken to provision a VDB using versions 2.7 and 3.0 of Delphix. As you can see, time to provision is independent of the size of the database being used. You will also notice the big drop in time taken to provision a VDB from 2.7 to 3.0. This gain comes from efficiency improvements in the provisioning process.


We also reduced the dependence on the type of workload or the amount of log activity present in the source database. The chart above shows a big drop in provision time for three different types of database workloads. Redo/Log activity increases going from Read Heavy workload, to OLTP to Write Heavy Workload. This enhancement is intended to make VDB Provision time more predictable to the user, improving the usability of the product.

Streamlined Replication Service Workflow

Replication service enables continuous user data replication from one Delphix server (source) onto another one (target). This is an essential component of our HA/DR solution. With 3.0 we have completely revamped the workflows for replication service. Inhouse experiments show close to 2x improvement in speed of replication. This comes from improvements in the network protocols used as well as enhancements to the replication service work flow. Customers will see improved utilization of their network link between the source and the target. Faster incremental replication will also mean reduced pressure on source delphix server.


I only touched upon some of the big performance enhancements made to the server in version 3.0. There are numerous smaller features added in the application stack and UI to improve overall responsiveness of the server. Culmination of all those is better usability of the product for our customers. Even with all the innovations made to the functionality of the software, 3.0 will again prove our continued focus on boosting performance.