Contents

Popular
 Contents

Ways of Optimization

Although Fiorano ESB architecture scales very well in a distributed environment, Fiorano users and developers are encouraged to adopt the strategies mentioned the sections below.

JVM Parameters

Tune the JVM Parameters according to memory consumption within your environment. The most important parameters are:

  • Xmx: Denotes the maximum java heap size. You may see the amount of memory you use exceeds the amount specified for the Xmx parameter. While Xmx limits the java heap size, java will allocate memory for other activities, including a stack for each thread. It is not unusual for the total memory consumption of the VM to exceed the value of –Xmx.
  • Xms: Initial java heap size.
  • Xss: Each thread in the JVM is allocated with a stack. The stack size limits the number of threads per JVM. If the stack size it too large, it will result in memory running out as each thread is allocated more memory than required. If the stack space is too small, there will eventually be an exception 'StackOverflow error'. If the stack space is too large, there will eventually be an exception similar to "Unable to create native thread" if the server tries to create more threads.

The default maximum JVM heap size is 64 MB. The Fiorano tools leave the JVM parameters as the default parameter, that is, 64 MB heap memory for each of the components. This JVM parameter can be fine tuned to reduce the memory footprint of individual microservice instances. 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 and Database Adapter.

The default heap size for server (Enterprise and Peer) can be set in the following files (that is, the file applicable based on the script being used to run the server):

  • $FIORANO_HOME/esb/server/bin/server.conf
  • $FIORANO_HOME/esb/fes/bin/fes.conf
  • $FIORANO_HOME/esb/fps/bin/fps.conf
Icon

For information on other recommended JVM parameters, please refer to "Recommendations" section and "Interpreting and Applying Recommendations" section in the Managing Peer Server Memory page.

Individual Components have 64 MB max heap size. This can be changed for each component by setting the JVM_PARAMS property in the Studio.


Figure 1: JVM_PARAMS Properties Screen

Separate Machines for Servers

Run the Enterprise Server and Peer Servers on different machines. This helps in getting additional available memory for components.

Distribute the Microservices

Distribute the flows across all the peers. Group the components inside flows logically so that a single unit of work is done using just one peer.

Interconnect Flows

Use Port Bindings to connect multiple flows running on a single Peer in place of External Business components. For example, if the Business Process definition requires data to flow from one process to another, then the output port of the last microservice in one Event Process is bound to a specific destination and then bound input port of the first microservice of the other Event Process to the same destination as specified on the output port earlier.

Example

To connect the business process: EventProcess1 and EventProcess2, perform the following actions:

  1. Click the output port of the last microservice in EventProcess1; the port turns blue in colour.
  2. In Properties panel, select the following values in the JMS Destination tab:
    • Destination Type: Topic
    • Custom Destination: Yes
    • Destination Name: Click the button present on the right side of the property and select 'EVENTS_TOPIC' (choose as per preference).
  3. Similarly, configure the same settings with the same destination on the input port of the first microservice present in EventProcess2.


Figure 2: Output Port Properties for the last microservice in EventProcess1


Figure 3: Input Port Properties for the first microservice in EventProcess2

Size of Event Flows

Avoid using large number of component instances per event flow. Keep the flows modular and distribute functionality across multiple flows.

Size of Messages

Keep the sizes of each message flowing through the Fiorano workflow small and not greater than 1 MB. If a given message is too large, then split the message into smaller ones using the XMLSplitter microservice, or in case of the Database adapter, limit the response size to an appropriate value.

Do not keep large XMLs in the Application Context. The Application Context should be used as storage for context and temporary results related to each message. Instead of carrying a binary attachment such as PDF, XML and Images with Tifosi Document/JMS Message or ESBRecord across the flow, make use of a SAN/NAS to store the attachment and carry forward only references.

Icon
  • Please note that 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 appropriate step to access the (large) binary as needed. Also, the binary attachment in most cases is not parsed at every step of the event process. As such, it is not needed at each step of the process and a simple reference will do.
  • Not all messages can be split. Splitting works only when each of the final messages become a standalone document after the split. For this reason, the XMLSplitter cannot be used for all large messages.

DB Microservice Tuning

Use a larger number of SQL queries per DB microservice instead of using separate DB microservices per SQL query. Additionally, use the DBQuery/DBProc components wherever possible in place of DB, as the latter is a much heavier component.

Adaptavist ThemeBuilder EngineAtlassian Confluence