Citrix NetScaler: Cache Microsoft App-V sequences

Written by Ingmar Verheij on January 3rd, 2014. Posted in Microsoft App-V, Netscaler

Citrix NetScaler: Cache Microsoft App-V sequencesRecently 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

Caching - None

 

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

Caching - IIS

 

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)

Caching - NetScaler Integrated Caching

 

 

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.

Packet Processing Flow Diagram

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.

Packet Processing Flow Diagram - HTTP Response Caching

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.

Packet Processing Flow Diagram - HTTP Request Caching

.

 

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.

Configuration - System - Settings Configure Basic Features - Integrated Caching

Or via CLI

 

 

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.

Configuration - Optimization - Integrated Caching - Change cache settingsCache Global Settings

Or via CLI

 

 

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.

Configuration - Optimization - Integrated Caching - Content Groups - AddConfigure Cache Content Group - Expiry MethodConfigure Cache Content Group - Memory

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

 

 

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.

Configuration - Optimization - Integrated Caching - Policies - AddConfigure Cache Policy

Or via CLI

 

 

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.

Configuration - Traffic Management - Load Balancing - Virtual Servers - OpenConfigure Virtal Server (Load Balancing)

Or via CLI

 

 

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

Configuration - Optimization - Integrated Caching - Statistics

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

Cache objects

 

 

 

.

Ingmar Verheij

At the time Ingmar wrote this article he worked for PepperByte as a Senior Consultant (up to May 2014). His work consisted of designing, migrating and troubleshooting Microsoft and Citrix infrastructures. He was working with technologies like Microsoft RDS, user environment management and (performance) monitoring. Ingmar is User Group leader of the Dutch Citrix User Group (DuCUG). RES Software named Ingmar RES Software Valued Professional in 2014.

More Posts - Website

Follow Me:
TwitterLinkedInGoogle Plus

Tags: , , , ,

Trackback from your site.

Comments (9)

  • Matthijs
    3 January 2014 at 11:22 |

    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

    • Ingmar Verheij+
      3 January 2014 at 11:26 |

      Glad you like it Matthijs. I’ve updated the Platinum requirement to Enterprise!

      Ingmar

  • 3 January 2014 at 20:26 |

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

    • 3 January 2014 at 20:47 |

      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

      • 3 January 2014 at 21:39 |

        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 !

    • Ingmar Verheij+
      4 January 2014 at 10:10 |

      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

  • Desmond Tam
    16 July 2014 at 21:12 |

    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.

  • Martin Fluck
    4 March 2015 at 20:03 |

    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.

Leave a comment

*

Donate

%d bloggers like this: