1. Home
  2. GLU.Guide
  3. GLU DevOps
  4. GLU.Engine Server Specifications

GLU.Engine Server Specifications


The GLU.Engine Server hosts the executable generated by the GLU.Console. It takes the form of a .WAR (if clients are using their own container) or a .JAR file (i.e. Springboot Container). Each ‘Application’ equates to one GLU.Engine and each GLU.Engine will require it’s own hardware as outlined below. This hardware recommendation is provided as a baseline / entry-level specification. GLU.Engine performance is CPU bound. If there is an expectation of high system performance, CPU should be increased. It is recommended for redundancy that a load balanced solution is put in place with multiple GLU.Engines running in parallel.

The GLU.Engine Runtime Environment is Version 17 (Java 17) – See install instructions in here.

If log aggregation is required, GLU has experience with using Filebeat to collect and send logs generated by the GLU.Engine to Elastic Stack. In this case, Filebeat should be installed on the same server as the GLU.Engine, refer to Elastic Stack instructions for Filebeat installation.  

Entry-Level Server Requirements

Disk200 GB disk space
Memory4 GB RAM for payload size of 150MB assuming 100 inflight transactions
CPU2 Dual Core CPU

Entry-Level OS Requirements

GLU.Engines are designed to operate within a Java virtual machine (JVM), ensuring compatibility with a wide range of operating systems (OS). While they are optimized for Linux environments, where shell scripts for starting, stopping, and managing the engine are provided, GLU.Engines can run on any OS that supports JVM.

Performance Settings

Where there is a requirement to handle higher levels of performance from the GLU.Engine adjusting the Java JVM settings will provide some useful options. Default JVM settings (as below) are embedded into the GLU.Engine startup (startup.sh) shell scripts and container settings, however these can be adjusted. These settings should be refined to match the required settings for the environment which the GLU.Engine will run in. These are configured in the JVM Settings tab within the Build Manager, GLU.Engine Settings tool.

Default GLU.Engine JVM Settings

-jar ./engine/GLUENGINE-1.4-SNAPSHOT.jar

Memory Settings

JMX memory settings can be helpful in performance tuning by allowing you to monitor and control the memory usage of your Java application. By adjusting these settings, you can improve the performance of your application by reducing the risk of running out of memory, minimising the impact of garbage collection (GC), and improving overall application responsiveness.

JMX memory settings that can be adjusted include:

  • Heap size: The amount of memory that the JVM allocates for use by the Java application. By adjusting the heap size, you can ensure that your application has enough memory to operate effectively, without running out of memory.
  • Non-heap memory: This includes memory used for class metadata, the JVM itself, and other internal JVM structures. By monitoring non-heap memory, you can detect and resolve memory leaks that can impact the performance of your application.
  • GC settings: As described below, JMX also provides control over GC settings, which can also impact memory usage and performance.

By monitoring and adjusting JMX memory settings, you can proactively manage the memory usage of your Java application, identify and resolve memory-related issues, and improve its performance. However, like with JMX GC settings, it’s important to carefully monitor and measure the impact of any changes to ensure that performance improvements are achieved and no unintended consequences occur.

The memory settings can be adjusted to reflect the size of the machine the GLU.Engine is deployed on. Memory allocation: You can adjust the amount of memory allocated to the Java virtual machine (JVM) using the -Xmx and -Xms options. For example, to allocate 2 GB of memory to the JVM, you can use the following option: -Xmx2048m

If the GE is running on an machine with multiple CPUs, this can be configured by adding this setting.

-XX:ConcGCThreads=8 where 8 would be adjusted to reflect the number of CPUs. So for an 8 CPU machine , leave this setting at 8, for a 2 CPU machine, change this setting to 2 (i.e. XX:ConcGCThreads=2), or for a 6 CPU machine , change this setting to 6 (i.e. XX:ConcGCThreads=6). The default is 1 CPU.

Garbage Collection Settings

Garbage collection (GC) is the process of automatically freeing memory occupied by objects that are no longer needed. By tuning JMX GC settings, you can control how the GC operates and improve the performance of your Java application.

GC settings that can be adjusted include:

  • The GC algorithm used (e.g., parallel, concurrent, etc.)
  • The heap size and generations (e.g., young, old, etc.)
  • The frequency and duration of GC pauses
  • The GC logging verbosity

By adjusting these settings, you can aim to reduce the GC overhead, minimize GC pauses, and improve application responsiveness. However, tuning JMX GC settings requires a good understanding of the underlying GC algorithms and the behavior of your application. It’s important to carefully monitor and measure the impact of any changes to ensure that performance improvements are achieved and no unintended consequences occur.

The goal in tuning garbage collection performance is to reduce the time required to perform a full garbage collection cycle. You should not attempt to tune the JVM to minimize the frequency of full garbage collections, because this generally results in an eventual forced garbage collection cycle that may take up to several full seconds to complete.

The simplest and most reliable way to achieve short garbage collection times over the lifetime of a production server is to use a fixed heap size with the collector and the parallel young generation collector, restricting the new generation size to at most one third of the overall heap.

  • -Xms100M  : initial heap size for the startup 
  • -Xmx500M : maximal heap size

These settings place boundaries on the heap size to increase the predictability of garbage collection. The heap size is limited in replica servers so that even Full GCs do not trigger SIP retransmissions. -Xms sets the starting size to prevent pauses caused by heap expansion.

-XX:+UseConcMarkSweepGC  : The Concurrent Mark Sweep (CMS) collector is designed for applications that prefer shorter garbage collection pauses and that can afford to share processor resources with the garbage collector while the application is running. Typically applications that have a relatively large set of long-lived data (a large tenured generation) and run on machines with two or more processors tend to benefit from the use of this collector. However, this collector should be considered for any application with a low pause time requirement. The CMS collector is enabled with the command-line option -XX:+UseConcMarkSweepGC.

Also, if it is set to ‘ON’, you need to remove the ScavengeBeforeFullGC setting which is enabled by default on your JVM. Once these changes have been applied, the GLU.Engine will need to be restarted.

For Windows (Beta) install this version: jdk-8u202-windows-x64.exe from here.

For more details of how to adjust the JVM settings which run the GLU.Engines please refer to Java SE documentation. The Java Standard Edition (SE) documentation provides detailed information on the available options and parameters for the Java runtime environment (JRE). You can access the documentation on the Oracle website here.

Was this article helpful?

Related Articles

Fill the form and we’ll contact you shortly

    I agree with

    We uses cookies to make your experience on this website better. Learn more
    Accept cookies