AppSync slower than full copy???

[rbmadison]

I am testing AppSync and have a 2GB application dat file that has a new version. The thinapp application is running locally on the PCs and I need to update it. I update the package via an HTTP packagepath and it starts doing the AppSync update and it takes over 3 minutes to update the local .dat file. If I do a simple copy of the new .dat file it takes 35 seconds. Below is the script I am using to update the application.

So it seems that AppSync is slower than a strait up copy. I assume this because it's doing the hash check on each block. Is there any logic that AppSync has to bypass the hash check and just do a full update which would be faster? Or am I missing something and it should be faster?

===================================================

Set TAManagement = CreateObject("ThinApp.Management")
Dim AppSyncPkg

TAOldPackage = "C:\Program Files\myapp1\myapp1.dat"
TANewPackageURL = "http://serverabc.mydomain.com/ThinApp/myapp1.dat"
AppSyncUpdate TAOldPackage, TANewPackageURL

Function AppSyncUpdate (TAOldPackage, TANewPackageURL)
     On Error Resume Next
     '=================================================
     ' Declare the ThinApp Package/File and open
     '=================================================
     Set AppSyncPkg = TAManagement.OpenPackage (TAOldPackage)
     '=================================================
     ' Attach to the package and do an AppSync Update
     '=================================================
     Sync = AppSyncPkg.AppSync (True, LCase(TANewPackageURL))
     msgbox(sync)
End Function

[rbmadison]

Could there be an option to check connectivity to the update location and if speed is greater than a percentage bypass the block hash check and just do a fully copy?

[TobyFruthParson]

RB,

Just curious - have you trolled all these:  http://blogs.vmware.com/thinapp/appsync/  ?

We are on the verge of testing AppSync for the first time, so this subject is of great interest to me.

As for whether or not the hash check can be disabled/bypassed, I have a thought.  We use SCCM to distribute software and updates.  SCCM uses BITS to move the data, and performs checksum/hash verification on the end point prior to implementation of change or advertisement.  In other words, if we are using SCCM to advertise an available software installation, the SCCM client will not present the advertisement until it knows all the blocks are good.  This mechanism reduces corrupt installation incidences.

I'm guessing that the main reason you're feeling the pain on the app in question is due to its size.  My guess is that the average 150-300MB AppSync won't be so bad.  I also don't know if you're using SSL for AppSync.  Perhaps SSL adds overhead.  Lastly, I saw a post not long ago on AppSync and antivirus.  http://www.tsmguru.com/vmware/vmware-thinapp-antivirus-best-practices.html