Configuring Execution Type

This section provides guidelines on Managing System Resources across Peer Servers together with recommendations on in-memory execution. The number of components running on a Peer Server must be optimized to optimize the load on that Peer Server and to utilize machine resources effectively. The sections below discuss available Launch Options.

• Separate Process
• In-memory
• Group Process

Refer the Manual Deployment section to know about Manual launch mode.

Using different Launch Modes

Separate Process

The number of components that can be launched on a Peer Server depends on the RAM availability. Users can launch more components on a machine with greater RAM than on one with less RAM.

However, there is a practical limitation on the number of components that can be safely launched on a Peer Server since all the components are launched as child processes of the Peer Server process. As the number of components on a particular Peer Server increases, it becomes difficult for the Peer Server to launch and stop the components. This can result in Request Timeout exceptions.

To avoid these timeout exceptions there is a need to distribute components across different Peer Servers.
The default timeout for application launch/stop in the Fiorano Studio is 100 seconds. Any server call is timed out after this duration. This value is configurable and can be increased to avoid frequent timeouts.

Fiorano recommends launching 60-75 components per Peer Server on a machine with 8 GB of RAM. The limit can be slightly greater on a machine with more RAM.

'Separate Process' mode is preferred for components with high memory footprint such as DB, WSStub, and WSConsumer with 32-bit JDK. If the message payload (request size at runtime) is huge and transformation is complex, use XSLT components in Separate Process mode.

'Separate Process' is the default Launch Mode; retain the default value until you get familiar with the environment and thereby decide to choose a different mode.

In Memory

In case of 'In memory' Launch, components are launched with the JVM of the Peer Server of the local machine. The default Heap memory allocated for servers in the Fiorano environment is 512 MB. Server heap memory can be increased by changing the –Xmx parameter value by editing the server.conf file located at FIORANO_HOME\esb\server\bin. For 'In Memory' Launch, it is recommended that the server Heap memory should be increased to the maximum limit, though this has the effect of allowing fewer threads within the overall Peer Server process.

In case of 32-bit machines, a java process can span up to a maximum of 1.6 GB of memory. Assuming that the heap size is set to the maximum, that is, 1.6 GB limit, the number of 'In Memory' components can be increased until the Peer server memory usage reaches this point (or within safe limits of this point, say approximately 70% of 1.6 GB).

In case of 64-bit machines, the java heap memory is relatively high (approximately 4 GB) and a larger number of components can be launched in In-memory. However, one needs to be careful in assigning more memory to the Peer Server process since more Heap memory has an impact on the number of threads that can be created by the JVM. As the heap memory of a process increase, the number of threads that can be created is less; this can have an adverse effect on Peer Server performance. As such, the precise heap memory allocated to the Peer Server JVM has to be determined by testing that particular configuration being run (that is, by running the full application to ensure there are no adverse effects on the system).

The in-memory mode is preferred for components with less memory footprint such as XSLT and CBR. Server JVM will be used while using components in this mode.

Launch Mode can be changed to 'In Memory' from Execution Type drop-down present in the Execution tab under Properties.

• Components that are launched In-memory should preferably have a lower memory footprint and lower CPU utilization. Components that have a large memory footprint or which take up greater amounts of CPU usage should not be launched In-memory as they will have a negative impact on the Peer Server functionality. For instance, if a component launched in a separate process continuously consumes, say, 70% of CPU then it cannot be launched In-memory.
• Fiorano suggests keeping the components as Separate Processes unless there's an absolute need to change the launch mode to In-memory. Running components In-memory dramatically decreases the overall memory utilization of an application since the number of JVMs launched is decreased
• Components that require low/high memory purely depends on the flow usage, load etc in the environment.
• Try to keep a balance between the number of processes and 'In Memory' components (threads in peer).

Group Process

In a scenario where RAM availability is limited, multiple components may be grouped to run in a single JVM using the Group Process launch mode.

Microservices can be launched in peer process or separate process. In the Separate Process mode, each microservice runs in a different JVM, where resources such as heap, stack, thread allocated to this process are not shared. Generally, microservices that process a large amount of data are launched in a separate JVM so that they do not affect the peer performance. In the In-memory mode, microservices are launched in the peer JVM, where they share the same resources of the peer. Microservices that are light weight are launched in the same JVM in which the peer runs.

Both of these launch modes have their own limitations:

• In-memory: It shares the resources with the peer server. If the microservices face some issues like thread leak or memory leak or take huge processing time, it affects the peer server performance.
• Separate Process: Involvement of multiple microservices increases the number of processes that are running in the system. Since a process is heavy weight with respect to consuming system resources, it results in choking up the system after a certain point. This situation forces to put forth a general recommendation to restrict the number of microservices in a peer.

To overcome the above-mentioned limitations upto a large extent, multiple microservices can be grouped together to launch in a single JVM sharing the same resources. This helps in reducing the total number of processes that are running in the system. Moreover, it avoids the risk of running critical microservices in the In-memory launch mode, hence eliminating the chance of a poor peer server performance. 

Groups act as runtime containers for processing microservices while peer server can dedicate itself managing the routes and destinations, and communicating metadata with microservices.

To run multiple microservices in a Single JVM, perform the following actions:

1. Create a Runtime Argument Named Configuration.
   
        Figure 3: Adding a runtime argument named configuration
   
2. Click the microservice in the orchestrator editor and go to the Properties view.
3. In the Execution tab, select the
   1. Execution Type: Group Process.
   2. Group process ID: The runtime argument named configuration that is created in Step 1.
       

   

    
   Figure 4: Choosing the Group Process launch mode for the selected microservice
    
4. To run another microservice in the same group, repeat steps 2 and 3 clicking the other microservice.
   
   

   

   
   Figure 5: Choosing the Group Process launch mode for the other microservice selected
    
5. Launch the event process.

By using the Group Process launch mode, the number of microservices that can be associated with a peer server can be substantially increased.

Changing the default Launch Mode

When it is clear that certain microservices in a particular environment are good to be in a different Launch Mode, these components can be made to stick to the preferred launch mode by changing the default value by editing their microservice in the Execution tab.

To change the default Launch Mode of a particular component:

1. In the Micro Service Repository panel, right-click the microservice for which default Launch Mode has to be changed and click Edit.
   
   

   

   
   Figure 6: Navigating to ServiceDescriptor.xml page to change default Launch mode
   

   If the Micro Service Repository panel is not found in the eStudio screen, open it from Window > Show View.

2. Click Execution tab present at the bottom of the ServiceDescriptor.xml page.

3. Scroll right and select the required Launch Mode from the Preferred drop-down present under Launch Configuration section.
4. To apply the changes made, click Save (else click File > Save or press CTRL+S).
   
   

   

   
   Figure 7: Changing the default Launch mode