• View Communities
    • Citrix Developer Network
      The place for unfiltered straight talk on Citrix products. Blogs, code downloads, best practices, APIs, and more can all be found here.
    • Citrix Ready Community Verified
      Does it work with Citrix? Application compatibility questions are a thing of the past with the new Citrix Community Verified site.
    • Blogs
      Learn the latest from the Citrix employees who are building application delivery infrastructure technologies.
    • Blogosphere
      The Citrix Blogosphere is a window into the thousands of conversations taking place about Citrix and Application Delivery.
  •  Sign In
The Citrix Blog
Personal Blog
Joseph Nord
Blogs
Profile
Related Tags
xenapp
Version 1 by Joseph Nord
on May 14, 2009 11:32.

 
compared with
Current by Joseph Nord
on May 14, 2009 11:33.

 
Key
These lines were removed. This word was removed.
These lines were added. This word was added.

View page history


There are 13 changes. View first change.

 <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:1; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:variable; mso-font-signature:0 0 0 0 0 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-1610611985 1073750139 0 0 159 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman";} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} -->
  
 I recommend: Never PreDeploy to XenApp Servers; never PreDeploy to XenDesktop clients.&nbsp; Always PreDeploy to notebooks.
  
 
 Background: Application Streaming supports server side execution, client side execution and client side execution that can go offline.&nbsp; These are controlled with publishing; should the application be available for offline or not, and via client side utilities (RadeDeploy) to optionally predeploy the execution content to the execution machine.&nbsp; Notice that PreDeploy is REQUIRED and *automatic* for offline, but that Deploy is optional for online.&nbsp;
  
 *What does "online" mean?*
  
 
 Online execution means that the streaming client has everything it needs to run the application available via the network.&nbsp; This means that it can "see" the Web Interface and can "see" the [Application Hub|http://community.citrix.com/pages/viewpage.action?pageId=50693548].&nbsp; By contrast, "offline" means that execution can still happen when the Web Interface and Application Hub are not available.
  
 
 In programmer speak, this is a 2*2 matrix with 4 possible states; one of which is invalid, offline without Deploy.&nbsp; I argue that Deploy + online, while valid, should not be used if the execution machine is inside the data center.&nbsp; If the network is "solid", don't Deploy.&nbsp; The corollary, if the machine is "sketchy", always publish for offline, with automatic deploy.&nbsp; This would get the number of states down from 3 to 2, which makes programmers happy.
  
 
 *What is Deploy*
  
 
 The guts of the streaming client are unaware of whether execution is server side or client side, online or offline.&nbsp; The execution engine brings execution content into the RadeCache (\Program files\Citrix\RadeCache) and fetches that execution content from a CAB file on a file server or web server (App Hub).&nbsp; In the online case, the cab file location is REALLY on a server.&nbsp; In the offline case, the streaming engine is pointed to the Deploy location on the local machine and does "local streaming".&nbsp; I call this streaming from one side of the hard disk to another; it was my idea back at the beginning and I must say that 4 years later, I'm pretty happy with myself.&nbsp; The caching activities in the streaming service and the kernel mode stuff in the file system driver are completely oblivious to "offline/online" and the streaming happens with the same code path in all cases; happy.
  
 Deploy is implemented by copying the execution content from the Application Hub and placing a copy of the Application Hub contents onto the execution machine; in \program files\citrix\deploy.&nbsp; Looking back, I wish we had put the RadeCache and Deploy directories one level deeper, but this is where they exist.&nbsp;
  
 *How to deploy*
  
 
 There are two ways to deploy.&nbsp; In the automatic case, the admin publishes an application and, to some users (you), publishes that application as available for offline.&nbsp; When you refresh applications in PNAgent (plugin for hosted apps), PNAgent gets a list of all of the applications that are available offline.&nbsp;
  
 The administrator has a choice when publishing.&nbsp; In the Access Management Console, the admin can say that the Pre-Deploy should happen immediately, or they can state that the Deploy should happen on the FIRST use of the application.&nbsp; I have not yet found a single admin who has gone with the Deploy on application refresh.&nbsp; Network storms at 8:05am are not how they want to start their day.&nbsp; This means that applications are not available for offline until the application has been run online, at least once. &nbsp;
  
 
 Eventually, the user (you) clicks on an icon to run the application.&nbsp; The application is run as if "online" and in the background, the server side content is xcopied down to the Deploy location on the execution machine.&nbsp; This automatic action does not occur if execution is on a XenApp server.&nbsp;
  
 The first use of the application continues in "online" configuration and it isn't until the next fresh launch of applications from that profile that the offline content is used.&nbsp; Looking back, it would have been better to have completely copied the offline content to the execution machine before ever running the application.&nbsp; The user feedback could then be ... "Copying your offline content, please go get a cup of coffee while I transfer 2GB to your machine".&nbsp; Instead, the user is faced with online execution, competing&nbsp; copying execution content from the file server into the RadeCache AND the streaming system copying the whole CAB file from the file server into the Deploy location and this presents a less than ideal first time experience, if the application is large.&nbsp; Yes, the offline deploy is done on an "idle thread", but single user, 2GHz + dual-CPU machines spend lots of time idle, so it competes.&nbsp; Eventually, you get the execution content local and further streaming from that profile is local to the execution machine AND available for offline.&nbsp;
  
 *How to PreDeploy to XenApp server*
  
 
 First, don't\!&nbsp; Second, you could use RadeDeploy.exe to command the deploy to happen, and if you do, it will occur.&nbsp; This would normally be done by software management system.&nbsp; The streaming client running on that server will at runtime look for the deploy content and if it is there, it will use it.&nbsp;
  
 
 *WHY NOT Deploy to servers\!*
  
 It isn't about the first execution.&nbsp; Yes, the first execution will be faster if you are PreDeployed.&nbsp; The application update though will be SLOWER.&nbsp; You first deploy.&nbsp; This happens once.&nbsp; Later, you will update the application numerous times.&nbsp; The update in "online" scenario is more efficient than the update in "offline".&nbsp; I should note that I really mean that the update is more efficient without PreDeploy.&nbsp; Online/Offline is not the trigger, the trigger is Deploy/NotDeploy - then again, one shouldn't deploy without offline, so they really are the same state.
  
 
 Consider a large application, say 1GB in size.&nbsp; If you PreDeploy it, you will have everything available for cache fills based on copies across the local disk; efficient.&nbsp; If instead, you don't PreDeploy it, some small percentage of the application will be runtime copied into the execution cache. &nbsp;
  
 When it comes time to update the applications MOST of the execution content will be unchanged.&nbsp; The Streaming Client will "KNOW" what files are the same, and which are different and it will "KNOW" this without a deep look at the files inside the CAB.&nbsp; In the online case, all of the "same" content can be immediatley promoted from version 1 to version 2 with no network involvement and this happens whether deployed or not.&nbsp; In the "deployed" case,&nbsp; the streaming system though needs to bring down EVERYTHING and this is very inefficient.&nbsp;
  
 In Streaming Client 1.1, this resulted in a full copy of the CAB file from the network server to the Deploy location on the client.&nbsp; Notice that it is a single file (the cab); the client copied the whole thing and this is not friendly to the network and worse, it is very bad if the user is remotely connected over a VPN; where Deploy SHOULD be used. &nbsp;
  
 In Streaming Client 1.2 (XenApp 5.0), the streaming client was enhanced to bring down only the "deltas" from version "old" to version "new".&nbsp; This is much more efficient network wise and brings Deploy case on-par with the online case, but it is still less efficient.&nbsp; Ultimately, the whole cab file is needed for both "old" and "new".&nbsp; The streaming system knows what has to exist, but the CAB file format does not allow update in place.&nbsp; To save network usage, the streaming client trades client side CPU and Disk activity to save network.&nbsp; This means that the Deploy update consists of a full un-cab of the CAB file, apply the updates, and full re-cab.&nbsp; For a 1GB application, this can take minutes\!&nbsp; 10s of minutes? &nbsp; What is my machine doing\!\!&nbsp; AArgh\!
  
 
 In a XenApp hosted environment, there is no need to pay the un-cab/re-cab penalty; the most efficient update is directly inside the execution cache and this has existed since the first release of Application Streaming.&nbsp; All of the above rocks thrown, are we going to make the Deploy/Offline case more efficient?&nbsp; Certainly\!
  
 *What should I do to optimize first time launch on the XenApp server?*
  
 Turn on "-e" [RadeRun switch|http://community.citrix.com/blogs/citrite/josephno/2008/03/28/RadeRunSwitches+-+Application+Streaming].&nbsp; Here is a [KB article|http://support.citrix.com/article/CTX115191] with more details.&nbsp; Execute one application from each profile, ONCE.&nbsp; Finally, be sure to then turn off \-e.&nbsp; Yes, I say turn it off because if you don't you will un-pack everything from the CAB on EVERY launch of any application for every user - which will be dog slow.&nbsp;&nbsp;&nbsp;
  
 You can achieve the same thing by running RadeRun.exe directly from the command line, specifying the \-e switch.&nbsp; This best done by automated systems, when the users aren't around.
  
 With the single run with "-e", everything will be extracted from the Application Hub and placed into the streaming execution cache.&nbsp; The streaming system will still do it's "just in time" programming, but it will pretty much never conclude that a cache fill is needed and the result is that execution will not suffer a first time launch penalty.
  
  
 Enjoy,&nbsp;
  
 Joe Nord
  
 Citrix Systems, Product Architect for Application Streaming and User Profile Manager.