Recently I wrote about streaming App-V 5 packages via HTTP. Using caching in IIS performance can be enhanced while resource consumption on the SMB share are minimized. Since we’re using HTTP for streaming it’s not unlikely a load balancer is used to divide the traffic to multiple App-V streaming servers adding another hop.

When a Citrix NetScaler is used to load balancing App-V Streaming Servers you could use Integrated Caching to cache resources. When resources are cached on the load balancer less network traffic is generated. Integrated Caching is part of the Platinum or Enterprise edition with Caching option.

Communication scenario

In a regular scenario where an App-V client downloads a package via HTTP, via a load balanced web server,  six steps are involved:

1. The App-V Client requests a file from the load balancer
2. The load balancer  forwards the request to the App-V Streaming Server
3. The App-V Streaming server requests the file via SMB to the SMB server
4. The SMB server sends the file to the App-V Streaming Server (retrieved from disk)
5. The App-V Streaming Server sends the file to the load balancer
6. The load balancer sends the file to the App-V Client

 

By enabling the caching feature (and increasing the cache size)  in IIS all subsequent request are reduced to four steps:

1. The App-V Client requests a file from the load balancer
2. The load balancer  forwards the request to the App-V Streaming Server
3. The App-V Streaming Server sends the file to the load balancer (retrieved from cache)
4. The load balancer sends the file to the App-V Client

 

When the Integrated Cache of the Citrix NetScaler is configured the steps could be reduces to two steps:

1. The App-V Client requests a file from the load balancer
2. The load balancer sends the file to the App-V Client (retrieved from cache)

 

 

Packet Processing Flow

A Citrix NetScaler processes packets in a pre-defined order. When traffic flows through a NetScaler it evaluates its feature sets, logging matching policy actions.

As can be seen in the diagram a packet is evaluated when it travels from the client to the server and again when it travels back from the client to the server. The last process is caching the returned object.

Typically the NetScaler system applies all matching actions after processing is complete, with integrated caching as one exception. This means that once a requested object is cached all other actions are no longer evaluated or applied. Keep this in mind if you need to apply for instance Request Rewrite of Response Rewrite  as they won’t be applied to cached objects.

.

 

Configuring the NetScaler

Here’s an example of how  you can configure a Citrix NetScaler to cache App-V packages using Integrated Caching.

 

Basic Features

The Integrated Caching features needs to be enabled, by default it’s disabled. In the Configuration tab go to Sytem > Settings and click on Configure basic features. Select the Integrated Caching feature and click OK.

Or via CLI

enable ns feature ic

 

 

Global Cache settings

To accommodate for large files to be cached the cache settings needs to be adjusted.Since App-V files are relatively large the memory usage limit should be sufficient to hold the App-V packages you want to cache. A Citrix NetScaler has 50% of it’s memory available for caching, so it’s vital the NetScaler has sufficient resources.

Besides having sufficient resources the limit should be configured so enable Integrated Caching to use the available memory. In the Configuration tab go to Optimization > Integrated Caching and click on  Change cache settings.At Memory Usage Limit (MB) enter the amount of memory that Integrated Caching is allowed to use.

Or via CLI

set cache parameter -memLimit 828

 

 

Content Group

Cached files are stored in a content group, each content group has it’s own configuration specifics. For the App-V sequences we’re creating a separate content group with a memory limit of 64GB (the maximum) and a maximum resource size of 2GB (the maximum).  You might want to adjust this to your needs.

In the Configuration tab go to Optimization > Integrated Caching > Content Groups and click on Add. Name the Content Group logically (for instance AppVContentGroup), select tab Memory and enter 1994752 the Do not cache, if size exceeds and 65535 as the Maximum memory usage limit.

Or via CLI (the CLI allows a larger amount for Do not cache, if size exceeds)

add cache contentgroup AppVContentGroup -maxResSize 2097151 -memLimit 65535

 

 

Cache Policy

As described earlier the processed packets are evaluated to determine if an action needs to be applied. To ensure App-V packages are cached a Cache Policy is created that caches files with the extension .appv.

In the Configuration tab go to Optimization > Integrated Caching > Policies and click on Add. Name the Cache Policy logically (for instance _cacheAppV5), set the action CACHE and store the object in the Content Group AppVContentGroup (created in the previous step). The Expression is set to HTTP.REQ.URL.PATH_AND_QUERY.ENDSWITH(.”appv”) to ensure all request that end with .appv are cached.

Or via CLI

add cache policy _cacheAppV5 -rule "HTTP.REQ.URL.PATH_AND_QUERY.ENDSWITH(\".appv\")" -action CACHE -storeingroup AppVContentGroup

 

 

Bind to load balancing Virtual Server

Finally the Cache Policy needs to be bound to one or more load balancing Virtual Server(s). Only packets that are load balanced via this Virtual Server will cache the objects that match the expression in the Cache Policy.

In the Configuration tab go to Traffic Management > Load Balancing > Virtual Servers select the Virtual Server where objects needs to be cached (for instance App-V Streaming Servers) and click on Open.

In the tab Policies select Cache (Request) and click on Insert Policy. Select the policy _cacheAppV5 (created in the previous step) and click on OK.

Or via CLI

bind lb vserver "APP-V STREAMING SERVERS" -policyName _cacheAppV5 -priority 1 -type REQUEST

 

 

Proof of the pudding

Now if I download the same App-V package (250Mb) as I did in the IIS caching article three times using a browser the statistics (via Optimization > Integrated Caching > Statistics) shows us 1 miss (the first request, which needed to be cached) and 2 hits (the subsequent requests) resulting in a Hit ratio of 66,67%.

If we look at the Cache Objects (via Optimization > Integrated Caching > View Cached Objects) the cached object is visible (Google Chrome.appv)

 

 

 

.