end point workstations slow down during update

Sounds like the same issue Sophos have had all through it's life and one I've mentioned several times before.

Not 100% sure if 9.5 uses the same update procedure but I'm betting it does the following:

1. Match the cicsync.upd file checksum with the CID checksum file and if different start the update procedure else skip to end.

2. Clone the entire cache folder for the package to update to a tempsavxp folder (that's at least a 100mb copy)

3. Download and integrate the new ide file (which might only be a couple of kb's in size) into the tempsavxp folder.

4. hash checksum the entire tempsavxp folder to create a new cidsync.upd file

5. remove the existing savxp folder from the cache directory

6. Clone the entire 100+MB tempsavxp folder back into the savxp folder and remove the tempsavxp folder.

7. Start the msi installation from the savxp folder data (this step usually only take a few seconds and can be seen as the Sophos system tray shield going grey for a moment).

Problem with this somewhat antiquated way of doing things is that eventually, hard drives will become heavily fragmented. The more fragmentation you have, the slower that the copy in steps 2 and 6 takes and also the hashing in step 4. You can see all this in action on a machine if you want. Wait for your CID to get updated and then on a client machine, simply watch the folder c:\program files\sophos\AutoUpdate\Cache (win xp) or c:\ProgramData\Sophos\Autoupdate\Cache (Vista/7). Cause an update on the client and watch the folders grow and shrink. So much for the 'only a few kb each update statement' - humbug!

Been saying this for ages to Sophos and frustratingly, nothings changing except that the package size increases through each release causing machines to fragment more quickly. It would be considerably better if Sophos could find a way of downloading the few KB update data and integrate it directly into the cache\savxp folder directly rather than use the cloning method.

You'll get some relief for a short while running a full defragment on the client's HD. Hope this helps.

Matt

Sounds like the same issue Sophos have had all through it's life and one I've mentioned several times before.

Not 100% sure if 9.5 uses the same update procedure but I'm betting it does the following:

1. Match the cicsync.upd file checksum with the CID checksum file and if different start the update procedure else skip to end.

2. Clone the entire cache folder for the package to update to a tempsavxp folder (that's at least a 100mb copy)

3. Download and integrate the new ide file (which might only be a couple of kb's in size) into the tempsavxp folder.

4. hash checksum the entire tempsavxp folder to create a new cidsync.upd file

5. remove the existing savxp folder from the cache directory

6. Clone the entire 100+MB tempsavxp folder back into the savxp folder and remove the tempsavxp folder.

7. Start the msi installation from the savxp folder data (this step usually only take a few seconds and can be seen as the Sophos system tray shield going grey for a moment).

Problem with this somewhat antiquated way of doing things is that eventually, hard drives will become heavily fragmented. The more fragmentation you have, the slower that the copy in steps 2 and 6 takes and also the hashing in step 4. You can see all this in action on a machine if you want. Wait for your CID to get updated and then on a client machine, simply watch the folder c:\program files\sophos\AutoUpdate\Cache (win xp) or c:\ProgramData\Sophos\Autoupdate\Cache (Vista/7). Cause an update on the client and watch the folders grow and shrink. So much for the 'only a few kb each update statement' - humbug!

Been saying this for ages to Sophos and frustratingly, nothings changing except that the package size increases through each release causing machines to fragment more quickly. It would be considerably better if Sophos could find a way of downloading the few KB update data and integrate it directly into the cache\savxp folder directly rather than use the cloning method.

You'll get some relief for a short while running a full defragment on the client's HD. Hope this helps.

Matt