The 5.2 release of Application Streaming which shipped with XenApp 5.0 Feature Pack 2 was focused on PERFORMANCE.  The biggest feature focused on second time application launch performance and was titled “Sandbox Reuse”. This post describes sandbox reuse in fine detail.

To discuss Sandbox Resuse, you must first discuss sandbox “not reuse”.  Consider the following graphic of a single user running multiple applications from a single Microsoft Office profile, MS Word, MS Excel and MS Outlook.

From the first release of Application Streaming, we have long described that all of the applications for a single user, from a single profile, share an isolation space.  Deep down in the innards of the isolation system, this was only conceptually accurate.

Yes, all of the isolated applications are isolated from the local machine and from applications in other profiles and yes, multiple applications from a single profile can talk to each other as if they were all installed together, but when you dig deep, there were really 3 sandboxes!  All three had equivalent isolation definitions, which means that Files, Registry, COM and Named Object are shared between them, but each of the launched applications is a SEPARATE sandbox.  The complexity of these things is diverse because there are lots of different things isolated, but stick with me on the concept; 1 user, 1 profile, 3 applications = 3 sandboxes.

First time launch vs. second time launch

The challenge is that setting up a sandbox is an EXPENSIVE operation, expensive primarily from a perspective of time, as in WALL VISIBLE time => SECONDS!

Here are some things that happen during sandbox create.

  • Notification to XenApp infrastructure, I am starting launch of “this” app (identified from publishing)
  • The IMA and management console uses this to know which apps are presently “running” (more below)
  • Query to XenApp infrastucture, am I license approved to run this app?
  • Don’t wait for a response, takes too long.  Next steps proceed asynchronous.
  • If published for offline, start automatic RadeDeploy – if deploy needed, start using a separate thread.
  • Open the CAB file (execution target). In 6.0, CAB file replaced with DIRECTORY, which is both more and less efficient.  I digress.  Key thing here, opening CAB file is slow operation.
  • Parse the isolation rules defined in SandboxData.xml (this is slow).
  • Check for application updates (RADE).  (fast given we’ve already parsed the profile).
  • Call the kernel sandbox driver and create an isolation sandbox (fast).
  • CreateProcess() or similar against the initial executable (suspended).  Application does not run yet.
  • Place application into sandbox so that all of its life is run isolated.  This includes installing hook infrastructure to filter registry, com, named objects.
  • Did that license request come back yet?  This time, wait until it does.
  • Release the application to run state
  • Wait up to 3 seconds for app to come to life.  If it fails to get GUI ready, display progress bar describing the application launch progress.
  • Done

SIMPLE!  Also, time consuming.  The most time consuming aspects are the CAB file open, the XenApp infrastructure communication for application launch/terminate notification, license check and the interestingly, the XML parse for the sandbox isolation rules.

All of the time consuming aspects of launching an application are for the most part redundant for second application launches for a single user, from a single profile.  Sandbox reuse changes the equation.

The key thing to know is that all processes in an isolation space, may start other processes.  Those other processes will also be isolated, and so will their children, and so on and so on.  Everything started “inside” stays inside.

Sandbox reuse adds a program to the isolation space, written by the streaming team specifically designed to always be run inside an isolation space.  This program is RadeLauncher.exe and it is added to EVERY started isolation space.  The end picture looks like this:

Recall again that application launches always start with RadeRun.exe.    In the sandbox reuse case, a small executable program is added into all started isolation sandboxes.  RadeLauncher.exe runs INSIDE isolation and is directly contacted as a function of RadeRun.  Instead of all the great overhead of the service creating isolation spaces, parsing sandbox isolation rules, opening CAB files and contacting the central publishing system, the already in place sandbox is utilized to initiate second application launches.

Being inside of isolation space, RadeLauncher.exe will issue a LOCAL ShellExecuteEx to run the initial executable.  This works out to be EQUIVALENT in speed to locally installed application executing another executable installed with it’s image.  That is, there is no overhead of getting things set up, because they are already set up.  Being “part of” the isolation space, RadeLauncher can issue application execution commands to the system and they are “captured” as part of the isolation world.  The EXISTING isolation space is reused to run additional processes, and it’s blindingly fast compared to the earlier method.

The elegance of this technique is bit-head stuff very impressive.

First time launch

None of this changes the FIRST time application launch performance.  The first app launch for isolated processes is pretty much the same as it was before sandbox reuse existed as a feature.  The value here is for SECOND time application launch and since there are lots more of those than first, this is high value.

XenApp Central Management looses some vision

For “ONLINE” Stream to Client, the XenApp infrastrucutre is normally “aware” of all of the application launch and terminates.  It is specifically not aware of application launch/terminate for “offline” applications, nor is it aware of streamed application which launch/terminate on XenApp Servers.  Well, technically it is aware of the server side stuff, but that is handled by hosted application publishing, so it’s a non-concern for streaming system.

With changes in sandbox reuse, the publishing infrastructure for stream to online hosted desktop and online physical client machines will be aware of only the FIRST application from each profile.  We made the decision consciously as a cost to implement sandbox reuse, knowing that there would be some loss in information.   For the most part, knowing that one application of a profile has run is sufficient to manage the usage information of applications in the profile.

RadeLaunch.exe is the key

If RadeLauncher is already running, then application launch is done as a local machine immediate execute (fast); all the overhead stuff of central communication is skipped and the application launch flies.  If it isn’t already running, then a new sandbox is created, old style.  Notice that “running” means that RadeLauncher.exe is already running for THIS profile, for THIS user.

Where can this be used?

This code first shipped with XenApp 5 Feature Pack 2, or the 5.2 release of the Application Streaming client, also known as the offline plugin.  This capability is available and automatic anywhere this client will run, which goes all the way back to Presentation Server 4.5 at current feature pack level if you overinstall the streaming client on top of the server.

RadeLauncher – Hangs out

Users who run applications from a single profile are highly likely to run more applications from that same profile.  Continuing with the Microsoft Office example profile, if you run MS Word to view a document, then terminate MS Word, and then run it again, RadeLauncher will still be there waiting for more application launch requests.  If this happens, it wins…  Notice in this case that “all” of the applications were briefly terminated, but the sandbox was not dismantled.

RadeLauncher hangs out for a configurable period of time after the final process, other than itself, of a sandbox terminates.  On 32 bit systems, HKLM/Software/Citrix/Rade/SandboxStatusMonitorPeriod (REG_DWORD).  The period is defined in MINUTES, defaults to 5 minutes and a value of 0 disables the sandbox reuse feature, returning to the behavior of the 1.2/1.3 clients.

If you have a large server, with lots of users, running lots of apps, you might see a whole bunch of instances of RadeLauncher.exe running.  This is expected.  You have ONE of these for each active sandbox on the machine.

Yeah, but can I kill it?

You betcha!  Happily kill all the RadeLauncher’s you want.  On the next application launch, if it isn’t around anymore, the code will start up a new isolation space, old style.  That new space will be linked up with the existing sandbox for isolation purposes, so it will be just like life before sandbox reuse.

This interestingly is important for people testing setting changes against isolation spaces.  If you adjust a streaming setting that will effect sandbox creates, and if you have RadeLauncher already running, then this will mystify the diagnosis of that setting because no new isolation space is created to exercise the setting.  The one that makes this show up the most is enabling the Debug console (EnableDebugConsole = 0x0001).   You make a change in the registry, launch an app and then do not see the thing that you expected to see.  How to get past?  Kill the RadeLauncher and relaunch, and you get the result you expected.

This is a big piece of very cool technology.  As I write, I should extend a complimentary nod to Madhav Chinta and Sam Raj who thought it all up and made it real.  Thanks guys.

Joe Nord

Citrix Systems Product Architect Application Streaming, Citrix Systems