~ Thamim Karim | Premier Field Engineer
Following on from my introduction to Shared Content Store (SCS) in this post I want to take you behind the scenes of what actually happens when we put our App-V 5.0 Client into this mode. The easiest way to understand how things work is by first looking at how things happen when launching an application for the first time in normal mode.
As you can see the first time the application is launched the App-V Streaming Filter interjects in order to provision the requested page to the client and in turn also commits that to the local disk within the cache. This means subsequent launches will not trigger any streaming of content as it will be held locally within cache. Now let’s take a look at how things how work when in Shared Content Store mode.
As you can see the only difference with Shared Content Store mode is that the assets are never committed onto the local disk. This means all subsequent launches will trigger the App-V Streaming Filter to intercept the page reads and stream the assets to the client. Therefore the assets of the application only ever reside in memory, the only part of the application that will be on disk is Feature Block 0, read more on that here.
When talking about SCS often questions are raised about impact and what additional overheads there are. The first thing to mention is that SCS is primarily designed for datacenter based solutions such as VDI/RDS environments, where fast connected storage is standard. Secondly as you have seen from the comparisons above, there is no actual overhead in terms of process, the only difference being that we do not commit to disk, in many environments this is a key benefit as it is helps to save premium disk space which would have otherwise been required to hold the App-V cache.
When talking about multi-user environments such as RDS where many users will be using the same platform at once, Windows Memory Management (WMM) will ensure efficiency of RAM usage for App-V applications as it would for any locally installed application. What this means is if one user is already using an App-V application, subsequent launches by other users on the same machine will not trigger multiple repeat streams of the content as WMM can utilize the shared pages already in memory. Read more about Windows Memory Management and how it works here.
In the above graphic we can take the example where one user logs on and launches a line of business application, every user thereafter who launches that same application does not cause WMM to trigger a page read from disk as the assets are already available as shared pages in RAM, therefore the streaming filter is not required to step in to retrieve the content.
The real impact to consider when utilizing SCS is the load on the storage solution itself.
In such scenarios you will have multiple clients requesting content from the content store in potentially a much more frequent and persistent fashion than you would have in normal mode.
Therefore it is important to test and size your backend storage provisioning sufficiently. The approach taken for this will differ vastly between environments and will depend on numerous factors such as connectivity, performance and content size.
There is of course the option to take a hybrid approach which means caching certain applications locally and letting SCS dynamically stream the remaining applications. For example you could put your client into SCS mode and mount your LOB applications locally using the Mount-AppvClientPackage PowerShell command.
Thamim Karim | Premier Field Engineer | Microsoft
Get the latest System Center news on Facebook and Twitter:
System Center All Up: http://blogs.technet.com/b/systemcenter/ System Center – Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/ System Center – Data Protection Manager Team blog: http://blogs.technet.com/dpm/ System Center – Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/ System Center – Operations Manager Team blog: http://blogs.technet.com/momteam/ System Center – Service Manager Team blog: http://blogs.technet.com/b/servicemanager System Center – Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm
Windows Intune: http://blogs.technet.com/b/windowsintune/ WSUS Support Team blog: http://blogs.technet.com/sus/ The AD RMS blog: http://blogs.technet.com/b/rmssupp/
The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/ The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/ The Forefront TMG blog: http://blogs.technet.com/b/isablog/ The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/
When using scs on vdi/rds especially on rds the memory sizeing on the rds host is important aswell. If you have lots of applications and lots of users on a rds host you need to have memory enough to cache all those apps in the WMM. If not its goin to re-read the data from the content store. So if you dont have enough RAM on your servers its going to be a massive impact on the SAN. Correct?
So on a RDS host, wouldnt it be cheaper to provision a "appv cache" disk residing on local disk if its virtualized or just use local disk if its not virtualized? And you would get faster starting times aswell for larger apps if you precache them.
Or am i missing something?
Hi there, I understand where you are coming from. I guess it all depends on what the impact to the SAN is, in many scenarios they are just as if not more efficient as locally attached disks, infact in some environments the storage will be physically enclosed in the blade chassis with the server servers themselves. RAM sizing is relevant but SCS shouldn't mean you aim to always read from RAM, SCS is designed to stream into RAM and the impact of this should be understood. I do agree in some scenarios where the SAN is not efficiently able to handle this impact a local cache may be preferable.