Citrix Machine Creation Services as of XenApp/XenDesktop 7.9 now provides the ability to write to memory with overflow to disk just like what is available with PVS using RAM w/ overflow to HDD. This greatly decreases write I/O so you don’t have to rely as much on the underlying storage or worry about hitting a bottleneck as you scale the desktop environment.
Previously with MCS temporary writes went to the delta/differencing disk attached to the VM. You now have the option of using temporary memory (RAM) to handle the caching of writes and a temporary disk in the event the RAM cache becomes full. When overflowing writes to a disk keep in mind that you don’t want this to be the point of a bottleneck so size the environment properly and place temporary disks on storage that won’t pose a big degradation in performance. The more RAM you assign to the memory cache the less chance writes will ever reach a disk. You could reduce IOPS by as much as 95% depending on how much RAM you can assign to the cache!
Temporary memory 256MB for VDI (desktop) and 2GB for Session Host (server) machines is recommended, which falls in line with what is recommended when using PVS RAM cache.
The temporary disk size is recommended to equal the free disk space of the VM plus the page file size. I normally set a 20GB cache size and get away with it but it all depends on your own environment.
With your Citrix Studio console open, running a XenApp or XenDesktop 7.9 farm, create a new Machine Catalog provisioned by MCS. Existing standard MCS catalogs cannot be converted to MCS as an MCSIO specific driver is installed to the VMs whilst being provisioned. You have the following options:
Memory allocated to cache (MB) – Provide a value in MB for how much RAM you want to dedicate to the cache. You have the option to use only the memory cache but be aware if the memory cache runs dry your VMs will become unstable and likely freeze or blue screen.
Disk cache size (GB) – Provide a value in GB for how much disk space you want to dedicate to the disk cache. You can choose to only create a disk cache and this means VMs will perform like they always have done producing the same IOPS as they would when provisioned without any cache. The good thing about using a disk cache is that you can separate writes on to different storage away from the base image and differencing disk. It is always recommended to create a disk cache when using RAM cache just to be safe in the event that the RAM cache runs out of free space.
Note that you also have the option to not configure any cache so MCS machines will be created and operate as they always have.
Click Yes. Complete the MCS Machine Catalog creation wizard. You will now have machines optimized for writes.
So using a simple file copy operation you can see the difference between a 2.6GB file copied to an MCS machine using cache vs. one without cache. Reaching a max of 110 write IOPS per second on a 15K spindle.
What about general daily tasks such as internet browsing and file browsing? You can see results below comparing normal operations on an MCS provisioned machine using cache vs. one without. There is no direct hit on IOPS when the cache is in use!
Using Performance Monitor on the Windows VDA you have a number of different counters that you can use to track performance and usage of the MCS cache. One particular useful counter is Cache memory used. This counter shows how much of the cache memory is in use. 
A simple test of copying a 710MB file to the VDA increased the Cached Used performance counter to accurately report what was now held in cache. Also note that 0 write IOPS were produced during the file copy. 
This is a great improvement for MCS provisioned machines and now puts MCS right up there beside PVS when it comes to IOPS performance.
Additional points:
- MCSIO works on Desktop/Server non-persistent and Session Host machines. Citrix Personal vDisks do not work with MCSIO ruling out persistent desktops.
- The more RAM you assign to a cache the less IOPS storage will ever have to deal with.
- You can not migrate existing MCS provisioned catalogs to MCSIO, you must recreate them.
- In the event that temporary memory space runs out, the temporary disk storage is used. Most recently used blocks of data are kept in memory for performance and least used are flushed to disk quite like how PVS RAM caching works with overflow to HDD.
- MCSIO can limit the amount of memory it uses in the event the VM becomes overloaded – the non-paged pool memory consumption on a machine is monitored and if it reaches 70% of available memory action is taken to suppress MCSIO memory usage annd instead write to disk until the non-paged pool memory consumption drops.
- Disk cache and memory cache size cannot be changed once the Machine Catalog has been created.