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:
- The App-V Client requests a file from the load balancer
- The load balancer forwards the request to the App-V Streaming Server
- The App-V Streaming server requests the file via SMB to the SMB server
- The SMB server sends the file to the App-V Streaming Server (retrieved from disk)
- The App-V Streaming Server sends the file to the load balancer
- 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:
- The App-V Client requests a file from the load balancer
- The load balancer forwards the request to the App-V Streaming Server
- The App-V Streaming Server sends the file to the load balancer (retrieved from cache)
- 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:
- The App-V Client requests a file from the load balancer
- 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)
.
English 
Nederlands
Hi Ingmar!
Superb blog! Good to see the cache feature used in this way. Two quick adds, typically you can use 50% of the available RAM of the NetScaler for caching (depends on the box). Second Integrated Caching is also available as an option on top of the Enterprise license!
NetScaler Rocks! 😉
Matthijs
Glad you like it Matthijs. I’ve updated the Platinum requirement to Enterprise!
Ingmar
Although I like the idea of using the NetScaler as a load balancer and caching device for app-v I guess there is more to consider than what’s already described.
A standard 5550 netscaler only has 8 gb a 8200 has 16 gb of memory, using it for app-v caching will fill up most of this memory pretty fast. Aside from that you will be using a lot of bandwidth as well, that’s why I would rather use it with DSR (when network supports it).
Matthijs is , of course, correct in stating you are able to use ic as an option in enterprise mode. That option unfortunately isn’t free and also not “cheap”.
Nothing in life comes for free Barry 😉 But let’s stay away from the pricing discussion on this blog and leave that to the sales and managers.
The solution Ingmar describes here is a very fast solution since all streams come from RAM memory. I guess you could look into solutions like the Cache Redirection feature to cache objects to an external caching server (Enterprise Lic). Also you can use ActionAnalytics to cache only the frequently used streams and get the rest from the back-end. Both come with a trade-off of lower performance since (asuming for external cache server) streams must be retrieved from disk.
Cheers! Matthijs
PS 8×00 = 32 GB
Whoops I misread on memory it indeed is 32GB.
I agree on staying away from pricing, the point I’m trying to make is that there could be a serious impact on design because of high amount of throughput and NetScaler sizing decisions. This isn’t anything new because we should investigate impact for any new service we set up.
The fact that we can use a NetScaler for these kind of optimizations and improvements proves the fact that it is an incredible platform !
Hi Barry,
Of course, the available memory of the MPX boxes could change the business case making it more viable to choose another option. Don’t forget you could also choose a VPX for this purpose which is only constrained by bandwitdh – depending on the model you choose (and doesn’t change by enabling Integrated Caching). Alternatives mentions by Matthijs are also viable.
Let’s say it depends on the situation, but for sure it an option to consider 😉
Cheers
Ingmar
Hi Ingmar,
Great post. I found it while doing some research on using App-V using HTTP streaming. I’m curious given that given Netscaler can be used for caching, have you used (or heard of anybody else using) a CDN platform to do similar caching? Cache-hit ratio is obviously a concern but depending on how users are mapped out there could be benefits. I’m just wondering if there’s any gotchas that you could see in such a deployment.
Disclosure: I work for Akamai Technologies, a CDN company. Any views and opinions expressed are my own, and not of my employer.
By far the best caching solution for App-V 5, granted this is SMB not HTTP, in my opinion is Server 2012 R2 Scale Out File Servers with CSV Block Cache enabled. This configuration allows SMB clients to access multiple file servers at the same time while delivering the blocks from server RAM for performance, with cluster resilience to boot.
I am a big fan of NetScaler but once your package library starts to run to 100s of applications the CSV Block Cache is more suitable to dealing with this amount of cache data than the NS cache is. In R2 the Block Cache can now use 80% of the file servers RAM.