Contents

Popular
 Contents

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. Launch Options - Separate Process and In-memory are discussed below.

Using 'Separate Process' Launch Mode

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.

Icon

'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.

Using 'In Memory' Launch Mode

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 less 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).

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.


Figure 1: In Memory Execution Type

Icon
  • 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 number of processes and 'In Memory' components (threads in peer).

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 2: Navigating to ServiceDescriptor.xml page to change default Launch mode

    Icon

    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 3: changing the default Launch mode
Adaptavist ThemeBuilder EngineAtlassian Confluence