About cloning Default Plug-in Policies Scalability Test

Products

• IT Management Suite
• Client Management Suite

Issue/Introduction

The customer asked if we had done some sort of testing with cloning Default plug-in policies and having a large amount of them.
 
This is his use case:
One of our sites (users of global instance of Altiris) is looking for a solution to manage multiple groups of assets (from post-update reboot point of view)
They are proposing the use of multiple default policies to manage these group's reboots.

The default policies we are referring to are the "Software Update Plug-in Policy"

 

I am looking to create a large number of these policies to manage update times and restart schedules for some very granularly configured targets at each of our sites
 

Question:

Is there a performance penalty for scaling up the Default Policy base (running 200+ default policies on a Notification server that serves 6-7 thousand endpoints) ?

Environment

ITMS 8.5, 8.6

Cause

Scalability test

Resolution

We reviewed the mentioned use case above. We reviewed the results of very detailed Patch scalability tests that we performed on the previous releases - unfortunately, they concentrate on the number of SWU (Software Update) policies created, etc. but don't take the number of plug-in policies created into account.

In our usual testing, we normally create no more than 3-4 plug-in policies.

 

Preliminary tests showed that 200+ cloned "Software Update Plug-in" policies should not be a big penalty. The main attention for Customer in this purpose is to create a correct resource target for each "Software Update Plug-in" policy, otherwise, if the client computer will be in resource target of 1st "Software Update Plug-in" policy and also in resource target of cloned another "Software Update Plug-in" policy, then client can receive not correct policy (only one "Software Update Plug-in" policy can be on client side, multiple "Software Update Plug-in" policies will not arrive to client), which will produce not expected results for Customer. 

At this point we can't Support the mentioned use case presented by the customer since we haven't conducted scalability tests on this area in specific. We will add this to our future releases as part of a separate testing/research QA task. Normally our guidance to the customers was to control different behavior using separate SWU policies created for different sets of computers (but this would be limited to controlling the installation time, not restart time). 

 

A feature request has been opened to add this scalability test to our QA process. No ETA (most likely next major release post-ITMS 8.6 RU3 release).

Additional Information

https://bsg-jira.broadcom.net/browse/CRE-10648