Best Practice 15 - Server Optimization
Best Practice 16 - Service Component Optimization

On any ESB platform, all implmented processes typically need to be tuned for performance. This is particularly true when the underlying platforms are themselves implemented in Java (as many ESB's are). Java. Although the recommendations noted in this section apply to the Fiorano ESB in particular, most ESBs support similar concepts and can be tuned in a similar manner.

Best Practice 15 - Server Optimization

• Enabling "optimized memory" settings for Servers

For best performance, it is important to tune the set the parameters of the Java Virtual Machine ( JVM ) on which all servers are run.

• Log Levels

In development and QA environments, it is recommended to set the log level for all servers to Config, i.e. the logs report all the configuration settings.

The Config level is typically one level more verbose than Errors (which is normally the default setting on most ESBs). By setting the log level to Config during development and QA, it becomes a lot easier to debug and test flows.

Once a flow is ready for production deployment, the log level can be set back to Errors (making the logs less verbose). Note that the default log level configuration in Fiorano products is Errors.

Best Practice 16 - Service Component Optimization

• Service threading options, (i.e., max/min number of sessions per component)

By default, a service component is single threaded, i.e. there is only one document is being processed by a service component at any given point. If the CPU is not at 100% utilization during a load test, then it is highly recommended to increase the number of sessions (i.e. threads) for the components in the event process. On the Fiorano ESB, the number of threads per component can be set within the Properties Window in the Event Process Orchestrator (as a Main property, in the LHS of the properties window).

While increasing the number of threads, always start off with the bottleneck component. There will be only bottleneck at a time. If you fix one bottleneck component, the bottleneck moves to another component in the flow. Determine the bottleneck by checking the CPU utilization on a per-component basis.

Using this technique, you can optimize the number of sessions/threads for each component based on the ability of the hardware to process the flow.

• JVM Parameters

The default maximum JVM heap size is 64MB for most JVMs. This parameter can be fine tuned to reduce the memory footprint of service components. The amount of memory allocated per JVM can (and should) be reduced for smaller components (such as flow-control components) or increased for memory-heavy components (such as XSLT, Database Adapter, etc.)

• Large Messages

Try to split the message into smaller XML messages using the XMLSplitter component. Any message over 1MB is considered a large message with the default service-component memory settings. The XML splitter allows a message to be split into multiple messages; take advantage of this component. Note that once a message is split, it has to be aggregated back at the target note using the Aggregator component.

Note: all messages cannot be split; splitting only works when each of the final messages after the split are standalone documents. For this reason, the XMLSplitter cannot be used for all large messages. It's use is restricted to those messages that that result in messages that can be independently processed by the flow after the original component is split.

• Message Attachments (Binary)

Instead of carrying large binary attachments (for eg: PDF, XML, Images etc., ) with TifosiDocument/JMSMessage or ESBRecord , all across a flow, make use of a SAN/NAS to store the attachment and carry forward only the reference.

The above technique works even when the flow executes across distributed machines. The technique is to store large binary attachments in one location (essentially, a file somewhere on the network), pass just a reference around the flow, and then on the final step access the (large) binary as needed.

Note also that the binary attachment, in most cases is not parsed at every step of the event process. As such, the entire document is not needed at each step of the process and a simple reference will do.

•Log Levels

In development and QA environments, it is recommended to set the log level for each Service Component to Config , i.e. the logs contain all the configuration settings.

The Config level is one level more verbose than Errors (which is the default setting). By setting the log level to Config during development and QA, it becomes a lot easier to debug and test flows.

Once a flow is ready for production deployment, the log level can be set back to Errors (making the logs less verbose). Note that the default log level configuration in Fiorano products is Errors .

• Running Components "in-memory" and using "on-route" XSLT transformations instead of explicit XSLT components

Ideally, it is best to run as many components as possible "in-memory" (i.e. within the memory space of the Peer Server on the Fiorano ESB). This optimizes memory utilization and increases the speed at which components exchange messages by over 600%.

Each time an XSLT component is used externally (i.e. in it's own separate process), it takes up additional memory; depending on JVM settings, this can be 64 MB or more of RAM. If there are several (20-40) transformations in a flow or set of related flows, the memory effects of using separate components become significant and the system may run low on memory; this can slow down the overall performance of the system and limit the number of flows that can run at a given time.

By performing transformations "on the route" (i.e. by right-clicking on the route and choosing Create Transformation to bring up the XSLT Editor), one ensures that (a) no separate component is created to perform the transformation, thus saving significant amounts of memory), and (b) the transformation runs in its own thread, ensuring that system threads are also available for other processing. Together, these two facts ensure that a larger number of event-processes can run on a single hardware platform.