The Delphix Engine is configured as a virtual machine either on-premise (using VMware or OpenStack) or in the cloud (Amazon Web Services), so the performance you get from it is determined by the resources (i.e. CPU, RAM, network, storage) allocated to it. Probably the biggest limiting factor on the performance of Delphix is storage. If you allocate sub-par storage to the virtual machine where the appliance resides, then you are not likely to meet high expectations for performance. The other resources, particularly network, can be important, especially the network between the Delphix Engine VM and the servers on which the "virtual databases" or "virtual file copies" reside. As with any network-attached storage, the performance of VDBs can be impacted by sub-par network configuration.
Another issue is where customers shoot themselves in the foot by not adhering to the requirements and recommendations that Delphix makes for the virtual machine itself. We require "reservations" on vRAM to ensure that the memory allocated to the VM is not "stolen" by other VMs or the hypervisor, but frequently customers ignore that because it is counter to their "standards". We also recommend "reservations" for vCPU for the same reason, and frequently that is also ignored due to "standards" for other VMs. The end result is that, as performance utilization in the cluster spikes, the Delphix VM is frequently starved for CPU and RAM, resulting in uneven performance or intermittent poor performance.
As with many things, you get from it what you put into it.
Hope this helps!