Client Management Suite

 View Only

Configuring Software Delivery Solution for Better Notification Server Performance 

Jun 06, 2007 12:27 PM

This article covers how to configure Software Delivery Solution to minimize the impacts on the Notification Server. Software Delivery Solution, depending on how it is used, may have very little impact to a large impact on the performance of the server. Many events are sent as due course through the scheduling, execution, and completing of a task. The Software Portal can also create loads on some internal scheduled tasks as well as event items.

Use the following items to tweak the way Software Delivery Solution reports events, how it creates, saves, or deletes internal items including Sequential Tasks.

Understanding the Impact

What load can Software Delivery Solution cause on the Notification Server? Understanding this, and understanding what reporting and or management needs you have, can allow you to configure Software Delivery to only impact the Notification Server as needed. The key is to scale down or eliminate those items that will not be utilized by your environment. Software Delivery impacts the following areas on the Notification Server:

  • Package Download and Update Events
  • Task Status Events
  • Execution Events
  • Software Portal Internal Tasks and Collections
  • Application Inventory
  • Database constraints

Package Download and Update Events

Any standard Notification Server Package (whether internal to a Solution or a standard Software Delivery Package) is downloaded through a series of steps, many of which involve the sending of a status NSE (of type AeX SWD Package). Each download or update of the package involves multiple small status NSEs being sent to the Notification Server and are logged in the table Evt_AeX_SWD_Package. While this can be completely disabled across all Solutions, Software Delivery provides the option to disable these for any particular Software Package. Unless you have a good business case to keep these enabled, for optimization purposed it is recommended to disable these. It can always be enabled again should a need arise to track the status of this package being downloaded server-side.

See this screenshot for the option:

By taking out the checkmark on this box you disable the sending of these package events. The corresponding status events will not be sent through the evtqfast data processing queue.

IMPACT: This will limit what NSE files are sent to the NS, lowering the NSE traffic to the evtqfast queue.

Task Status Events

Not to be confused with the execution return code of the Inventory Tasks, Status events include the following event types:

  • New Job - The Altiris Agent has received a new Task.
  • Job Updated - The Agent received an update to an existing Task.
  • Download Complete - Agent has completed downloading the Package associated with a Task.
  • Job Activated - A Task previously disabled has been reactivated.
  • Job Removed - A Task has been removed after successful completion.
  • New Package - The Agent has received notice of a New Package associated with a Task.
  • Package Removed - A package has been deleted from the client system.
  • Package To Be Removed - A package is no longer active and is scheduled to be delete after the time set according to the Package's settings.
  • Package Updated - A Package has been updated due to changes to the snapshot.
  • Unable to check package - Unable to check the status of a Package.

All these events are captured in the 'Evt_AeX_SWD_Status' table.

Depending on the business needs and environment, these statuses may be unnecessary if it's the execution status or lack thereof that is the prime events for tracking. These events are by default enabled on a Software Delivery Task, enabling all of these types of events to be sent to the Notification Server.

The UI provides a checkbox for these types of events. See the following screenshot:

To disable Task Status events (reminder: This does not include execution statuses) uncheck this box followed by clicking the 'Apply' button.

IMPACT: This will limit what NSE files are sent to the NS, lowering the NSE traffic to the evtqfast queue.

Execution Events

Execution Events should not be disabled; however on a truly taxed Notification Server there is a method to disable Execution Events.

  1. Apply NS SP3 R4 to upgrade the install dir\Altiris\Altiris Agent\AeXSWDAgent.dll version to 6.0.1524.0 (You must upgrade the Altiris Agent to apply this new DLL version).
  2. On the client machines create a new registry value "ConsiderExecutionEventsAsVerbose" at the location "HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\Software Delivery" and set the value to "1". This will consider the execution events as a part of verbose reporting.
  3. A registry update can be rolled out to machines via Software Delivery Solution to apply this.

It is recommended to keep execution events activated as that is how you can track what machines have run a particular Software Delivery Task or not, and if not, what occurred during the execution.

IMPACT: Not recommended as execution reporting is disabled, but if implemented, this will limit what NSE files are sent to the NS, lowering the NSE traffic to the evtqfast queue.

Software Portal Internal Tasks and Collections

When a user requests a piece of software via the Software Portal, a Task and Collection are created. The task uses all defaults for the selected software-package/program, and assigns the collection created to the task. The collection is a single computer Collection.

The task is assigned to run 'As soon as the computer is notified (ASAP)'. By so doing, this task will be scheduled for that computer for as long as the task exists, but the computer will run it once, and then mark it as run in the AeXSWDPolicy.xml file, so though the task still shows up in the client policy XML file, it will only run once. However that means this Task will be active both on the server and client after the request is made.

The collection follows a pattern with the naming convention: SWRCollection_%COMPUTERNAME%. This collection contains one member: the computer the request came from, as labeled in the Collection [Name]. This collection, though small, does constitute an single point of update for any of the Collection Updates on the Server side. Potentially there can be as many collections of this type as managed computers on the Notification Server, or more if systems are retired or removed.

Sequential Tasks also create a large number of items, including a Sequential Task ID that's unique from the parent Sequential Task the request came from. It also includes a task for every single execution event inside the Sequential Task, again different from those of the parent task.

The key is to enable swift purging of these types of items. The purge items are accessed as shown:

It is recommended to set this to purge every 1 day. Software Portal jobs should execute very quickly after a request, and thus the Task and Collection are not required for the future.

IMPACT: Essential collection updating has far fewer collections to cycle through; Client Configuration composition will not include these tasks, shortening both the processing time and the data being sent across the wire to the client systems.

Application Inventory

Application Inventory is an Inventory piece that was to be incorporated into an Application State Management framework for Software Delivery. However this was never utilized and is a fairly useless function that most customers do not use. The following items are created/maintained when any Application Inventory task is enabled:

  1. Creates Application items for every piece of software it finds on any system. This means that random applications end up being included even if only one system has that particular piece of software installed/in the file system.
  2. Creates Installer items for every installer found on the system.
  3. Any application relationship between applications and installers is logged per system.

You may ask "But I want this type of information, so why not use it here?" The problem stems from the lack of features that makes use of this information. Inventory Solution can collect all this information, and already has much of that information by default. PCT Solution at one point used it, but that product is End of Life. Disable these Tasks! They are located in the Console under Configuration > Software Management > Software Delivery > Windows > Application Inventory.

IMPACT: No Application Inventory is sent to the server for processing. No Application relationships are created, causing various issues with queries in the ItemReference table.

Database constraints

Most of the above items constitute database items that take up space. Most are relatively minor, but taken as a whole they equal a decent amount of space (especially with Application Inventory); but more than that they take up space on some major tables that are used for a variety of background tasks and Reports. Items include:

  • ItemReference entries for many stored-procedures under most solutions
  • Event data for Tasks, downloads, and executions -- any report stemming from these are affected
  • Duplicate Inventory on installed software and existing installers
  • Hidden Tasks and Collections stressing Collection updates and Client Configuration request compilations

Conclusion

It is highly recommended to understand the needs of your organization to understand what changes can be made in the environment without impacting how Software Delivery Solution data is used. It is recommended to review each item for possible usage in your environment before optimizing the settings for performance reasons.

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

Nov 30, 2007 04:46 PM

Delta and In-Use updates every 30 minutes; those updates are intense for us, as we have a lot of dynamic collections (well, a lot of collections period).

Nov 29, 2007 02:15 PM

There are several types of collection updates. The Delta update just verifies those that have changed.
The full update is the one that should be run overnight which is the most intensive. This is the update that runs when you hit the Update All Collections button

Nov 28, 2007 07:36 PM

Static collections are stored in the collection membership table, same as automatic collections; however, automatic collections need to be re-evaluated every collection update interval, which can be quite an intensive operation if you have a lot of automatic collections.
For us, it updates every 30 minutes, and it takes at least 5 minutes each time to update all of our automatic collections.

Aug 19, 2007 10:51 AM

There are two types of collections that can be created, dynamic and static. Dynamic collections have a far lower performance cost on the dataabse compared to static collections, as they run one query in order to populate itself, whereas a static collection has to query the database for each resource that has been made its member.

Aug 17, 2007 07:13 PM

How does having many automatic collections affect performance? Should there be a limit? Should manual collections be used as often as possible?

Related Entries and Links

No Related Resource entered.