Performance considarations?

[Martijn Kools]

So I'm testing Citrix App Layering and I'm pretty excited about it, I see it as a good replacement for our super slow App-V environment. I've published my first image to PVS and it boots and runs nicely. It even auto converts my VHD to VHDX by using the Powershell script which works like a charm however, it feels a bit slower than a vdisk built from scratch which was cleaned-up using DISM after update installation and defragmented before converting it to a vdisk.

 

So what are the performance considarations with App Layering? Do we need to run defrag on each layer? Or on the final vdisk before converting it to VHDX? And a Dism /cleanup on the OS and Office application layer? Any other options to increase performance / reduce footprint?

 

Thanks.

 

 

 

 

[Gunther Anderson]

Other people will have better answers, but I can tell you what I know.  Defragmentation is not necessary, because when we finalize a layer, we copy the files from the dis downloaded from your hypervisor into a new virtual disk inside the ELM.  That automatically defragments the files as a side-effect.  It doesn't matter how fragmented the package disk is; we don't clone that disk.  We just steal the files.

 

Also, if you enable any Elastic Layer mode, things will always run a little slower (most noticeably during login and some program startups) because of the registry virtualization.  So if you truly want to compare apples to apples, test with Elastic Layers set to None in your Image. 

 

Basically, anything you would normally do to optimize a non-App-Layering image, you can always experiment with in your Platform Layer.  I'm sure some optimizations are toxic to usm but I never argue with experimentation.  And the Platform Layer is disposable, so you can do all the nefarious things you want to there.

[Mathieu Bruston1709157835]

Hello,

 

for my part, I mount the finalized vdisk on PVS server and run defrag directly on It.

When done, I unmount the VHD/VHDX file and copy to others PVS servers.

 

Advantage : no files are locked by system during the defrag.

 

Regards,

[Mathieu Bruston1709157835]

7 minutes ago, Martijn Kools said:

If you run a defrag on a mounted VHDX, won't the size of the VHDX increase?

 

According to the above reply this is not required. Do you see any fragmentation or do you just run a scripted defrag?

 

i don't see that the VDX increase significantly, and for fragmentation there is a little. 

 

for the performance , it's could be the EL mode as gunthera said. When a user logs on the vdi , the app layering service will check the store, even if there is no EL app published.

 

If I refer to VMware AppVolume, there is the same behavior. logon a more slower due to AppVolume service.

 

Bye

[Rob Zylowski]

On defrag i dont think there should be much benefit the way layers are created and merged there should not be any significant fragmentation.  If you are adding a version to change the layer substantially just create a new layer instead.

 

On the VHDX even though I wrote the script I don't think I would bother with it.  The biggest benefits of VHDX are for writing to it rather than reading from it.

 

I do think the slowness is likely due to the change in system architecture due to visualizing the registry and file system.  That said i think it will be mostly noticeable when opening applications and mainly opening them the first time within a session.  Unless an applications does an unusual amount of registry calls when its running it will not likely affect running apps that much.  Of course the perceived performance by users is often based on things like how fast does the application open.  So maybe a little education is necessary if you want the flexibility that elastic layering provides. 

 

Remember too that performance of the share will be very important for performance of elastic layers.

 

Rob

[Martijn Kools]

Cool, thanks again for the super fast feedback! I will experiment some more.

 

 

 

[Martijn Kools]

1 minute ago, Mathieu Bruston1709157835 said:

Hello,

 

for my part, I mount the finalized vdisk on PVS server and run defrag directly on It.

When done, I unmount the VHD/VHDX file and copy to others PVS servers.

 

Advantage : no files are locked by system during the defrag.

 

Regards,

 

If you run a defrag on a mounted VHDX, won't the size of the VHDX increase?

 

According to the above reply this is not required. Do you see any fragmentation or do you just run a scripted defrag?

 

 

[Martijn Kools]

Well I don't see the point of messing with PVS vdisk versions anyway but I do see the VHDX ends up being 4 GB smaller than my VHD. So it could be useful to save some space.

 

 

[Mathieu Bruston1709157835]

2 minutes ago, Martijn Kools said:

Well I don't see the point of messing with PVS vdisk versions anyway but I do see the VHDX ends up being 4 GB smaller than my VHD. So it could be useful to save some space.

 

 

If you use Windows 2012 R2 or above , you can enable Windows Data Deduplication. on my PVS server, I save arround 60% of space for 15/20 vdisks ( I use local disk for the moment before try a new Isilon NAS)

[Akinola Oke]

 

On ‎12‎/‎27‎/‎2017 at 4:04 PM, Rob Zylowski1709158051 said:

On defrag i dont think there should be much benefit the way layers are created and merged there should not be any significant fragmentation.  If you are adding a version to change the layer substantially just create a new layer instead.

 

On the VHDX even though I wrote the script I don't think I would bother with it.  The biggest benefits of VHDX are for writing to it rather than reading from it.

 

I do think the slowness is likely due to the change in system architecture due to visualizing the registry and file system.  That said i think it will be mostly noticeable when opening applications and mainly opening them the first time within a session.  Unless an applications does an unusual amount of registry calls when its running it will not likely affect running apps that much.  Of course the perceived performance by users is often based on things like how fast does the application open.  So maybe a little education is necessary if you want the flexibility that elastic layering provides. 

 

Remember too that performance of the share will be very important for performance of elastic layers.

 

Rob

 

I believe "App Layering" has envolved for quite a while, would it still be necessary to convert the vdisk to VHDX for any performance gain?

[Rob Zylowski]

I personally have never thought converting the vDisk was worth the effort.  But its easy to test and decide for yourself.