We have been using Sophos successfully for over a year. However, we have recently noticed that workstations using Endpoint Security and Control v9.5 experience slowdowns once a day. We have our client update settings configured to get updates every 12 hours and it appears as though the workstation slowdowns are due to the client getting its updates. Has anyone else experienced this issue?
Matt,
Your breakdown of the updating sequence in the version 9.5 client is about right. Here’’’’s our description:
This approach was taken because it attempts to maintain a consistent file set on the machine that is “known good”. The checksum calculations are necessary to verify the integrity of the download.
We have been working on a couple of specific performance-related issues in the updating client. Recently, as part of our on-going maintenance cycle, we identified and fixed a potential problem where the http update process could use high CPU levels in certain circumstances during the download period. Also, our next major endpoint release is currently scheduled to include a change specifically to address some of the file-copying issues you mention. The approach we’’’’re using is to replace file copying with “hard links”, which means that the file isn’’’’t actually copied, but that two or more files shown in Windows Explorer actually refer to the same file on the disk. Using this technique, a file copy step actually just creates a new link to an existing file, which is quicker than copying the file. Also, since no actual copying is done, it should have less of an impact on disk fragmentation. We’’’’ve also made a slight improvement to the final file-move step, which is currently done one file at a time – now we do it in one step on the whole folder. Some of our tests suggest that this new version can reduce the CPU time taken by the download stage of the update cycle by about 40%. Here’’’’s an example:
Windows XP SP3, running on Pentium 4, 3Ghz, 512 Mb RAM.
Average time taken for an IDE update cycle using shipping product: 18.3 seconds.
Average time taken for an IDE update cycle using new client: 10.8 seconds.
Obviously, any improvement will depend on the details of the machine you’’’’re using, but it’’’’s our hope that you will notice an improvement in the next product release.
To answer one of your other points, we acknowledge that the overall package size has increased over recent releases. In fact, this is a trend that is likely to continue in forthcoming releases as we add significant new functionality into our endpoint product set. To help offset this, we are currently investigating options to enable use of http compression to reduce the size of downloads. However, we want to make sure that this doesn’’’’t add a performance hit on the client when the compressed files are unpacked. More fundamentally, we’’’’re also investigating options for moving our endpoint updating away from the existing file structure of the “Central Installation Directory”. We have an alternative format known as the Sophos Data Distribution System (SDDS), that uses a single file store where no copying is needed during an update cycle. It also brings other advantages such as being designed for use with http caching proxy servers to help reduce the network impact of file downloads, and finer control over which products and versions are updated.
Those are longer-term changes, but hopefully indicate to you that we are working on making improvements in this area of our product set.
Endpoint Product Management & Endpoint Deployment & Updating Team
Matt,
Your breakdown of the updating sequence in the version 9.5 client is about right. Here’’’’s our description:
This approach was taken because it attempts to maintain a consistent file set on the machine that is “known good”. The checksum calculations are necessary to verify the integrity of the download.
We have been working on a couple of specific performance-related issues in the updating client. Recently, as part of our on-going maintenance cycle, we identified and fixed a potential problem where the http update process could use high CPU levels in certain circumstances during the download period. Also, our next major endpoint release is currently scheduled to include a change specifically to address some of the file-copying issues you mention. The approach we’’’’re using is to replace file copying with “hard links”, which means that the file isn’’’’t actually copied, but that two or more files shown in Windows Explorer actually refer to the same file on the disk. Using this technique, a file copy step actually just creates a new link to an existing file, which is quicker than copying the file. Also, since no actual copying is done, it should have less of an impact on disk fragmentation. We’’’’ve also made a slight improvement to the final file-move step, which is currently done one file at a time – now we do it in one step on the whole folder. Some of our tests suggest that this new version can reduce the CPU time taken by the download stage of the update cycle by about 40%. Here’’’’s an example:
Windows XP SP3, running on Pentium 4, 3Ghz, 512 Mb RAM.
Average time taken for an IDE update cycle using shipping product: 18.3 seconds.
Average time taken for an IDE update cycle using new client: 10.8 seconds.
Obviously, any improvement will depend on the details of the machine you’’’’re using, but it’’’’s our hope that you will notice an improvement in the next product release.
To answer one of your other points, we acknowledge that the overall package size has increased over recent releases. In fact, this is a trend that is likely to continue in forthcoming releases as we add significant new functionality into our endpoint product set. To help offset this, we are currently investigating options to enable use of http compression to reduce the size of downloads. However, we want to make sure that this doesn’’’’t add a performance hit on the client when the compressed files are unpacked. More fundamentally, we’’’’re also investigating options for moving our endpoint updating away from the existing file structure of the “Central Installation Directory”. We have an alternative format known as the Sophos Data Distribution System (SDDS), that uses a single file store where no copying is needed during an update cycle. It also brings other advantages such as being designed for use with http caching proxy servers to help reduce the network impact of file downloads, and finer control over which products and versions are updated.
Those are longer-term changes, but hopefully indicate to you that we are working on making improvements in this area of our product set.
Endpoint Product Management & Endpoint Deployment & Updating Team
