Upgrading? Need advice? Let us know!

Hi Matt,

Thanks for your comments.

I am one of the SUM developers, and hopefully I'll be able to shed some light on what is happening in your case.

Each additional subscription does indeed put a significant load on SUM, as SUM will treat each independently when performing consistency checks on the products. SUM is generally designed to be very careful about the correctness of downloads. This means that if for instance you have the SAV XP product in more than one subscription, then when creating and distributing the CIDs it will indeed use significant CPU time to check the correctness of the SAV XP product multiple times.

However, none of this should affect the functioning of SUM for three reasons:

Firstly, even if you have the same product in multiple subscriptions, SUM will only download the files once, so you shouldn't suffer from additional network overhead.

Secondly, (apart from the load on your server) it doesn't matter if the update takes longer than the check time (which is actually 10 minutes by default). If an update is already occurring, then the check is skipped.

Thirdly, SUM will only do the CPU-heavy distribute if the product has actually changed. This should only be a few times each day.

I've put together a test case on a virtual machine to try to replicate your configuration: I've got 7 subscriptions each with a variety of products in it (including some of our more obscure platforms).

On my system the initial update took nearly 30 minutes. This is a little slow (due to the multiple complex subscriptions), but it did complete successfully.

Subsequent to this, a check for updates takes about a minute. Though I've just noticed a defect in SUM that means this is taking longer than it should: hopefully we'll get this down to a few seconds in a maintenance release.

To summarise: yes, if you've got lots of subscriptions SUM can take a while to update, but this shouldn't compromise it's functioning or the protection of your systems.

I'll contact you directly to see if we can understand what you are trying to do with your configuration, and whether we can come up with an improvement for you, or whether this is a case we are going to need to optimise in future SUM development.

I hope that was informative. Please feel to post again if you would like more clarification.

Cheers,

John Reynolds

Hi Matt,

Thanks for your comments.

I am one of the SUM developers, and hopefully I'll be able to shed some light on what is happening in your case.

Each additional subscription does indeed put a significant load on SUM, as SUM will treat each independently when performing consistency checks on the products. SUM is generally designed to be very careful about the correctness of downloads. This means that if for instance you have the SAV XP product in more than one subscription, then when creating and distributing the CIDs it will indeed use significant CPU time to check the correctness of the SAV XP product multiple times.

However, none of this should affect the functioning of SUM for three reasons:

Firstly, even if you have the same product in multiple subscriptions, SUM will only download the files once, so you shouldn't suffer from additional network overhead.

Secondly, (apart from the load on your server) it doesn't matter if the update takes longer than the check time (which is actually 10 minutes by default). If an update is already occurring, then the check is skipped.

Thirdly, SUM will only do the CPU-heavy distribute if the product has actually changed. This should only be a few times each day.

I've put together a test case on a virtual machine to try to replicate your configuration: I've got 7 subscriptions each with a variety of products in it (including some of our more obscure platforms).

On my system the initial update took nearly 30 minutes. This is a little slow (due to the multiple complex subscriptions), but it did complete successfully.

Subsequent to this, a check for updates takes about a minute. Though I've just noticed a defect in SUM that means this is taking longer than it should: hopefully we'll get this down to a few seconds in a maintenance release.

To summarise: yes, if you've got lots of subscriptions SUM can take a while to update, but this shouldn't compromise it's functioning or the protection of your systems.

I'll contact you directly to see if we can understand what you are trying to do with your configuration, and whether we can come up with an improvement for you, or whether this is a case we are going to need to optimise in future SUM development.

I hope that was informative. Please feel to post again if you would like more clarification.

Cheers,

John Reynolds