Tune and scale clusters

The tasks for tuning a B2Bi cluster architecture can be grouped in the following categories:

  • Distribution – Adding nodes to the cluster.
  • Scaling – Adding processing capacity to a node in the cluster.
  • Tuning – Task optimization and node configuration.
Caution   Performance optimization must be done on a case-by-case basis. An implementation that processes a low volume of large file size messages requires a different configuration from an implementation that processes a high volume of small messages. Do not adjust parameters unless you are experienced with B2Bi.

Processing factors

Before adjusting parameters, keep in mind that processing is heavily influenced by the following:

  • Available (primary) memory
    • Avoid swapping
  • CPU/cores, speed and size
    • Allow parallel processing
    • Be aware that this is typically a bottleneck when processing large volumes of large files with complex operations
  • Shared disk speed
    • B2Bi generates numerous synchronized disk writes to ensure data persistence; easily 50 disk write actions for 5 activities (simple flow)
    • Be aware that this is typically a bottleneck when processing large volumes of small messages
  • Network capacity

When the file requires integration (transformation, enrichment, validation, and so forth), the following elements can impact performance:

  • Complexity of the mapping (number of elements mapped)
  • Number of steps required in the service (each step requires multiple disk write operations, which consume time and resources)
  • Global design of the mapping (optimizations depending on the bottleneck)
    • Input file can be split in multiple sub-messages, resulting in better usage of the CPU but requiring more I/O

B2Bi scaling

To improve throughput, you can install additional nodes on your network and then add them in the System Management section of the B2Bi user interface.

See Add a cluster node.

In B2Bi implementations, there is a 1:1 relationship between trading engines and integration engines: Adding a trading engine (running on a specific node) implies the addition of an additional integration engine as well.

The effect on performance of adding B2Bi nodes is not linear. That is, adding a second node does not double the throughput capacity. There are many factors that have an influence on performance (CPU / memory / disk / network). The results of adding nodes depends on the root causes of your message-processing bottlenecks.

Integration engine scaling and tuning

Initial configuration

During B2Bi Server installation the installer user is prompted to provide a value for the number of CPUs to use for B2Bi Server operations. The installer uses this value to calculate initial settings for:

  • Number of of Processing Engines for HME1, HME2, and HME3
  • Number of Logger Tasks

B2Bi balances the number of Integration Engine processes with the number of processors. Depending on the number of CPUs set during the installation, an implicit scaling is done, with the following results:

CPU #PE/ HME1 #PE/ HME2 #PE/ HME3 #PE/ HME4 Logger tasks
2 2 2 4 1 2
4 4 4 8 1 4
6 8 8 16 1 8

Modify number of processing engines and logger tasks

After installation, to modify the number of processing engines and HMEs assigned to tasks, and the number of logger tasks, you use the System Profile Manager application of the Integration Engine System Manager tool set. For information about how to use the System Profile Manager, see Use System Profile Manager.

Fail safe operation

For the B2Bi integration engine, the default run mode is “fail safe”. This is the safest operating mode in terms of persistence to the disk, but it takes away a percentage of processing power because this persistence slows down the throughput. The percentage of processing required depends on the production context. As a general rule, turning off the “fail safe” mode benefits small size / high volume patterns significantly more than large file / low volume patterns.

Caution   Turning fail safe operation off is generally not supported for cluster installations. It can be turned off for single node clusters or certain Axway-verified and approved cluster installations with no node-specific caching toward the shared file system.

Log level

Logging can become a performance bottleneck, especially in situations in which the system needs to handle a high volume of small messages. To avoid this, you can change the log level to reduce the amount of log information per transaction.

To set the log level you work in the System Profile Manager > Environment tab > Logging subtab.

For details see Logging subtab.

Trading engine tuning

For information on trading engine tuning tasks, see Tune the trading engine.

Related Links