Video Screencast Help

Size of Upgraded Package

Created: 15 May 2013 • Updated: 13 Aug 2013 | 4 comments
This issue has been solved. See solution.


I have a important question on upgraded packages. I explain it on Firefox package

My version 1 pacakge of firefox 17.0.2 has a size cca 20MB.

Once I did upgrade package to get version 2, Firefox 17.0.5. The upgraded package has size cca 40MB. Once I look inside of the xpf file I see that upgraded package contains the whole version 1 and also whole version 2.

Now I take a clean workstation which has no Firefox instaled at all. Once I stream down to workstation upgraded package version 2 the whole 40MB is streamed.


Why the whole upgraded package is streamed down even with the old version 1 which is not needed at all?

My undestand is that the pursope of upgrade poackage is to stream down only a deltas between version 1 and version2.

Upgrade package is always bigger and bigger than the previous version which defeat the whole purpose of upgrade then.


Operating Systems:

Comments 4 CommentsJump to latest comment

Ganesh.B's picture

Hi Alexander,

     Is this 40 MB of Version is the cache size you're seeing in AppMgrGUI after all the blocks are collected, meant 100% cached. 

This 40 MB is what firefox 17.x package size is when completely streamed.  Even if you stream Firefox 17.0.2 which is your Version 1 to offline ready,  I firmly believe it will be around same 35 to 40 MB and not 20 MB which is your .xpf package size.  We should not be comparing the size of the .xpf file and cache size as it's two different entity.

You should also try creating Firefox 17.0.5 as direct package, stream it to client and compare the cache size between upgrade package and same version of firefox created directly.

To answer your questions:-

  During package upgrade, SWS streams down only the delta and never brings down the whole file structure or uninstall and restream new version.  With Version 1, create some bookmarks in V1 and upgrade to Version 2.  You should still see all the booksmarks since only delta was applied. 

While creating multiple version .xpf package in composer,  we need earlier versions to be stored in same .xpf, so our package upgrade process will be successfuly.  Also, this helps people to upgrade from any lower version to higher version.  Like, we can upgrade to Version 5, from any lower version V1, V2, V3 and V4. 

I've 3 version of firefox 14, 16 and 18 and this is what Cache size and .XPF package size is

 Firefox 14 Version 1

   .XPF package size -  21 MB

  Cache size when streamed to offline - 37 MB

Firefox 16, Version 2

  .XPF package size - 40 MB

  Cache size, when Streamed to offline (directly or upgrade from V1) - 40 MB

Firefox 18, Version 3

  .XPF package size - 60 MB

 Cache size when streamed to offline (directly or upgrade from V2) -  44 MB

delvalled's picture

Hello Alexander,

Let me see if I can address some of your concerns.

Why the whole upgraded package is streamed down even with the old version 1 which is not needed at all?

When you launch an upgraded package, the client streams the original package and then merges the delta from the upgrade in the package. Let me share the details of how I tested this. I created the following packages using Virtual Composer 6.1 SP8:

  1. Application Package: Firefox v1.xpf (23mb) (vendor version 16.0.2)
  2. Upgrade Package:Firefox v2.xpf (47mb) (vendor version 19.0)
  3. Upgrade Package:Firefox v3.xpf (72mb) (vendor version 21.0)

We can see the xpf file is getting larger as we continue upgrading... more on that later.

From the Streaming Console, I provisioned all three packages to my user.

From my client machine, I streamed each version of the Firefox package, one at a time, and checked the total size. Here is a screenshot of the version 1 package and we can see the total size is 40mb.

Firefox v1 streaming details.png

Here's a screenshot from the version 2 package and we can see the total size is only 43mb.

Firefox v2 streaming details.png

And finally, here is package version 3 with a total size of 46mb.

Firefox v3 streaming details.png

If the streamed package was cumulative in size, then we would expect that the total amount of data streamed would be over 130mb by the time we stream version 3, but this is not the case. 

My undestand is that the pursope of upgrade poackage is to stream down only a deltas between version 1 and version2.

That is correct; the upgrade package will only stream the delta between the original and the upgrade. During the capture process, only the files that were created/modified are included in the upgrade layer. In the case above, we are installing a major upgrade of Firefox (version 16.0.2  -> 17.0 -> 21.0). The vendor's installer replaces almost every single file in the original package. What does this mean for our delta? It means that all the modified files are included in the delta. This means that the streaming agent will dump the existing files in favor of the modified files in the upgrade layer.

So how do we make good use of the delta feature in package upgrades? By only making minor revisions to the original package. We could continue with Firefox, but let's use an example with Notepad++. I've created a version 1 package which is just the standard installation. Later, I decided I want to include two new plugins. I open Virtual Composer, create an upgrade package, and begin the capture process. I add the new plugins, end the capture, then compile the package. This completes the version 2 package, but wait, let's go another step further and let's add 8 more plugins. I followed the same process as before to create a version 3 package. Take a look at the size of these xpf packages.

  1. Application Package: Notepad++ v1.xpf (8mb)
  2. Upgrade Package: Notepad++ v2.xpf (11mb)
  3. Upgrade Package: Notepad++ v3.xpf (15mb)

If these packages followed the same process as with the Firefox experiment above, you might think that the packages would increase in size like 8mb,16mb, 24mb, but we are only capturing the delta between the original layer and the upgrade. In this case, the upgrade only adds a couple of megabytes each time. If we compare the contents of each xpf file using 7-zip, we can plainly see the delta is captured:

Notepad++ delta versions.png

When I streamed Notepad++ followed by the upgraded layers, only the files that were in the delta were streamed to the client; the existing files in the cache were retained.

Upgrade package is always bigger and bigger than the previous version which defeat the whole purpose of upgrade then.

It's true, an upgrade package will be bigger than the original, but how big it becomes depends on how much has changed in between the original package and the upgrade package. Using the delta functionality, we will only stream the files that have changed between versions. I hope the answers above help to explain how it all works together.

Kind regards,


ad0170's picture

Hello Danny

Thanks you very much for your explanation. Now I understand it fully.


ateamrh's picture

Hi Alexander,

If you feel you got the information that you need, then please mark this thread as answered.

Kind Regards