Management Pack Cookdown Analyzer is designed to find cookdown-related problems in your management pack that may result in performance issues. Cookdown is an advanced concept in Operations Manager 2007, where individual workflows that are found to be pulling information from the same source are consolidated such that only one workflow is launched. By ensuring that cookdown can occur properly, performance issues caused by a system being overloaded by too many workflows running at once can be prevented.

Running MP Cookdown Analyzer

MP Cookdown Analyzer is an option on the Tools menu in the Authoring console. When you run MP Cookdown Analyzer, it produces a report that shows analysis of the workflows defined in the active management pack. Use this report to access the MP Cookdown Analyzer documentation, which explains the cookdown concept and provides possible solutions for the cookdown-related issues found in the management packs.

To use MP Cookdown Analyzer
  1. While a management pack is loaded into the Authoring console, click Tools, and click Perform Cookdown Analysis. This opens the MP Cookdown Analyzer window.

  2. If specifying classes with a small number of instances, use the steps in the following section, Specifying Classes with a Small Number of Instances.

  3. When configuration is complete, click Generate a Report.

The legend on the report explains what it means for a workflow to be categorized as red or yellow in analysis. If any classes were selected as having very few instances, these classes will be shown at the top of the report as being ignored.

The summary section details workflows that are found to have criteria that impact cookdown-related performance, the interval at which these workflows run, and the class which these workflows target. A management pack author can use this information to determine whether it is necessary to drill into details for a specific workflow. For example, a management pack author may decide that for a workflow that has an interval of 604800 seconds (one week), the workflow runs so infrequently that fixing any cookdown-related performance issues is not necessary.

The Details section breaks each workflow into its component modules, and shows which performance issues were found with each module. This section provides hyperlinks for the user to drill into the documentation that accompanies the tool. This documentation explains the conditions that cause specific problems and provides possible solutions.

Specifying Classes with a Small Number of Instances

MP Cookdown Analyzer provides the management pack author with the option to specify classes defined in their management pack that will always have a very small number of instances per agent in a customer environment. The cookdown analyzer will not analyze workflows that target such classes. Workflows occur once per class on an agent, and consolidating a workflow that runs only a very small number of times into a workflow that runs only once will not provide a significant or noticeable performance benefit.

To specify classes with a small number of instances
  1. While a management pack is loaded into the Authoring console, click Tools, and click Perform Cookdown Analysis. This opens the MP Cookdown Analyzer window.

  2. Select the I want to specify classes with a small number of instances check box.

  3. In the list, select each class in your management pack that you want to exclude from analysis. Note that classes that are found to have a very small number of instances (for example, classes derived from types that always have only one instance per agent, classes derived from singletons that have no key properties, and classes hosted on singletons that have no key properties) are not displayed in the list for selection.

  4. When the appropriate selections have been made, click Generate Report to view the results of the cookdown analysis.

Troubleshooting

Error: In a workflow that contains two performance-critical modules, the overall categorization of the workflow is based on only the first module.

Solution: This occurs by design of the tool. Having more than one performance-critical module in one workflow is a rare case. In this situation, regard the criticality of the second performance-critical module in addition to the first. If the second module is in a yellow or red state, consider fixing this workflow so that cookdown is not broken for the second module.