Streaming Client 1.0 was the original release of the client that accompanied Presentation Server 4.5.
Streaming Client 1.1 shipped with PS 4.5 HRP1, around September 2007. It included some performance enhancements that are not widely understood. This blog post brings a bit of attention to some good work. Under the hood work, but still good work. The upcoming Delaware release will include additional performance enhancements.
The Streaming Profiler has a few jobs. The primary one is to “observe” the actions of an installation program, prevent the installation items from really occurring and “write down” what the installer tried to do to the machine. This writing down part includes two primary items, the “file system” and the “registry”.
If you peek inside an application streaming profile, you will see a “.profile” file. This is the highest level file. It is XML formatted data that describes everything needed for publishing. There are a series of “CAB files” that hold the execution content for 1 or more execution platforms. These “CAB files” are the backing store that support execution. They are often called “execution targets” and they store the registry content and disk content for actually running the program.
The registry data is inside a .TAB file and isn’t important for today’s conversation. The disk content is stored below the \Device folder in the CAB file and holds everything that was “installed” to the file system – potentially, lots of stuff.
Now – why did we use CAB files to hold this?
Is an excellent question and one of great debate in the development circles. Instead of a compressed CAB, the content could just as easily be a directory with everything stored below that directory. The CAB was used to faciliate offline access and make it a boolean decision on “its there” or “its not there”. Looking back, this was doable without a CAB, but we have what we have right now.
The trick! Efficient access to CABs. Accessing files inside a CAB is not as efficient as accessing files beneath sub-directories.
When creating an isolation sandbox, the streaming and isolation system needs to “know” what was stored during profiling. When an application at runtime does a “DIR”, the response to that directory enumeration uses information that “isn’t there”. The information is provided to the application based on what “was there” at profiling time rather than was “is there” at runtime. If the application then opens a file that isn’t there, the streaming system makes the file “present” before completing the file operation. This last item is a “cache fill” and is the basis of the “streaming” part of Application Streaming.
Consider: How do you construct a list of all the files in the CAB?
In the Streaming Client 1.0, this list was constructed as a part of creating the isolation sandbox. That is, created at runtime.
it was assumed that an administrator might update the CAB file “behind the back” of the Streaming Profiler. With this, the contents of the CAB were scanned at application launch and the directory structure for enumeration was built in memory based on the scan. Hindsight says that this was a BRUTAL activity for performance. Actually, it only was a problem for “large” applications, but here it was a real concern. The problem is that it happens EVERY launch, not just first time launch, so this makes the inefficiency a big thing to be concerned about. It was a big enough concern that we “fixed it” in 1.1.
In Streaming Client 1.1 (4.5 HRP1), the Streaming Profiler was enhanced to store the directory enumeration data as part of saving the profile (target). With this data available in a single place, the Streaming Client could “skip” the DIR /S on the CAB file and speed application launch — Greatly faster! A side note is that the admin can no longer update the CAB file behind the back of the Streaming Profiler. No worries, nobody was doing that anyway.
To get the benefit of the meta-data stored with the execution target, the existing profile needs to be loaded into a 1.1 level Streaming Profiler, the Target needs to be edited and then saved. Done. The 1.1 Streaming Client looks for the meta-data. If its there, it uses it. A 1.0 level Streaming Client will access the files of the CAB “the old way” and this makes the profiles backward and forward compatible even with the change. Computer Science is fun stuff!
What’s the future…
In Streaming Client 1.2, this is taken a step further to change the compression of the CABs in a manner that’s more friendly with WanScaler and happens to give a great benefit to first time launch performance. I’ll save that for a later blog entry, probably “post-Delaware”. For now, you should know that the CAB file in 1.0 and 1.1 is created in a format that allows more efficient single file extracts than does the default formatting from CABARC or similar tools.
In a dream, I’ll shoot CAB files completely. Truth is, won’t get there anytime soon.
Product Architect Application Streaming
Citrix Systems Fort Lauderdale, FL