Shared Content Store in Microsoft App-V 5.0 – Behind the Scenes

發行項
07/22/2013

~ 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.

Normal Mode (Default)

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.

Shared Content Store

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.

Impact

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.

Multi-user

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.

Multi-machine

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.

Hybrid

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 :