ibmint optimize server command

Use the ibmint optimize server command to optimize the startup time of an integration server.

Usage notes

For information about how and when to use the ibmint optimize server command, see Optimizing the startup time for an independent integration server.

When you run the command, you need to take the following items into consideration:
  • The work directory passed in needs to be a valid server work directory. If it is not, then the command reports an error.
  • A server.conf.yaml file must be present.
  • The content of the server's work directory must be valid with no missing dependencies.
  • If any content is missing, the command fails and a log is displayed showing what is missing.
  • If the server's work directory contains independent resources (server level resources in IIB V10 and earlier), then an attempt is made to use the defaultApplication that is specified in the server.conf.yaml file. If this file is not present, then the --default-application parameter can be used.
  • If a default application name is required but not supplied, then the command fails.
  • Any BAR files that are present in an integration server work directory are unpacked.
  • If the BAR file contains server-level resources, they are moved into the default application.
  • The deployed resources that were in the BAR file are evaluated in the same way as any other deployed resource.
  • The work directory must contain at least one message flow for the analysis to be successful. If no valid message flows are found, then a warning is reported.
  • If work directory content is such that an integration server requires every component, then a server.components.yaml is not created and the user is informed. (This scenario is highly unlikely.)
  • All work directory content is analyzed irrespective of whether it is used at run time or not. For example:
    • All policies are considered whether they are used by message flows or not.
    • All shared library content is analyzed whether they are referenced by applications or not.
    • All applications and message flows are analyzed whether they are going to run or not.
    • Subflows are not scanned individually but their content is considered when they are instantiated in the message flows that use them.
  • The --verbose parameter can be used to show what steps were taken during the analysis and why components were enabled (More details appear in the Parameters section of this document).
  • It is possible to override the analysis results by using the -enable and --disable parameters. These parameters name components as they appear in the server.components.yaml file. For a component that falls under a subsection in the server.components.yaml, the component can be specified as <subsection>/<component>, or by <component> . For example, --enable ResourceManagers/GlobalCache or --enable GlobalCache. The longer form might be preferred for clarity. Overrides are applied after the analysis is complete and so they do not appear in the --verbose log output. If you want to enable or disable multiple components, you can specify overrides multiple times.
    • Expect to use the --enable and --disable parameters only in rare circumstances. In most cases, the analysis provides a satisfactory optimization without further user intervention.
    • The --enable and --disable parameters are simpler to use than hand-editing or script-editing the server.components.yaml file after analysis, but you must check that they result in a consistently optimized integration server.
  • The --trace parameter produces service trace as with all other ibmint commands.
  • You can run the ibmint optimize server multiple times on the same work directory. If the command is successful, any existing server.components.yaml file is removed, and a new server.components.yaml file replaces it. No settings are preserved from previous invocations.

Supported platforms

  • Windows
  • Linux®
  • Linux on POWER®
  • Linux on Z
  • AIX®
  • IBM® z/OS® Container Extensions (zCX)

Purpose

You can use the ibmint optimize server command to optimize the startup time for an integration server. Optimization is achieved by disabling unused server components so that they are no longer initialized, thus saving CPU time on startup. The command automatically detects unused components by scanning the contents of the server's work directory, examining the server.conf.yaml file, the deployed flows, and other contents to determine which components are needed for the server to function correctly.

Optimization can also reduce the base memory foot-print of the IntegrationServer process. Total memory usage then continues to be reduced but by an amount that varies widely depending on the amount of message processing.

Syntax

Read syntax diagramSkip visual syntax diagramibmint optimize server --work-directory  directory --enable component name --disable component name --default-applicationapplication name --verbose  --trace filePath --help 

Parameters

--work-directory directory
The path to the integration server's work directory to be optimized. A server.components.yaml file is written that indicates which components to exclude.
--enable component name
Specify that a particular component must be enabled. This parameter takes precedence over the work directory analysis. Can be specified multiple times to enable multiple components. The names of available components can be found in the sample.server.components.yaml file that is shipped in the product. For more information, see Optimizing the startup time for an independent integration server.
--disable component name
Specify that a particular component must not be enabled. This takes precedence over the work directory analysis. Can be specified multiple times to disable multiple components. The names of available components can be found in the sample.server.components.yaml file that is shipped in the product. For more information, see Optimizing the startup time for an independent integration server.
--default-application application name
The name of the application under which the server places any independent resources.
--verbose
Output details from the work directory analysis to show which components were found to be required.
The messages that are displayed in this output can be split into two main categories:
A) Messages that show what resources are being navigated to and analyzed:
  • BIP15243I: Analyzing server configuration.
  • BIP15244I: Analyzing application '&1'.
  • BIP15245I: Analyzing service '&1'.
  • BIP15246I: Analyzing REST API '&1'.
  • BIP15247I: Analyzing library '&1'.
  • BIP15248I: Analyzing shared library '&1'.
  • BIP15249I: Analyzing policy project '&1'.
  • BIP15250I: Analyzing message flow '&1'.
  • BIP15251I: Analyzing message flow node '&1'.
  • BIP15252I: Analyzing subflow instance '&1'.
  • BIP15253I: Analyzing policy '&1'.
B) Messages that indicate when a component is required based on their content:
  • BIP15254I: The component '&1' is required for message flow node '&2' of type '&3'.
  • BIP15255I: The component '&1' is required for deployed resource '&2'.
  • BIP15256I: The component '&1' is required for policy '&2' of type '&3'.
  • BIP15257I: The component '&1' is required for YAML configuration setting '&2' with value '&3.
--trace filePath
Send verbose internal trace to the specified file.

Examples

The following shows a command that would optimize the work directory C:\Work\Development\V13\Server1:
ibmint optimize server --work-directory C:\Work\Development\V13\Server1
The following shows a command that would optimize the work directory C:\Work\Development\V13\Server1, override enabling the JVM and disable two other components:
ibmint optimize server --work-directory C:\Work\Development\V13\Server1 --enable JVM --disable NodeJS --disable ResourceManagers/GlobalCache