GLU.Engine Server Specifications


The GLU.Engine Server hosts the executable generated by the GLU.Console to provide integration. 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 or system performance concerns, 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.

OPTIONAL – If log aggregation is required.

GLU has experience with using Filebeats to collect and send logs generated by the GLU.Engine to Elastic Search or Elastic Logstash . 

Filebeat should be installed on the same server as the GLU.Engine if this is required. Please refer to Elastic’s install instructions for filebeats if this is required. 

GLU.Engine – Entry-Level Server Requirements

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

GLU.Engine – Entry-Level OS Requirements

Operating SystemSpecification
UbuntuVERSION=”18.04.2 LTS (Bionic Beaver)”ID=ubuntuID_LIKE=debianVERSION_ID=”18.04″HOME_URL=”
SUSENAME=”SLES”VERSION=”15″PRETTY_NAME=”SUSE Linux Enterprise Server 15″
Amazon Linux – CentOS 7.x.VERSION=”2″ID=”amzn”ID_LIKE=”centos rhel fedora”PRETTY_NAME=”Amazon Linux 2″HOME_URL=”
Amazon Linux 2 – CentOS 6.xopenjdk version “1.8.0_191″ID=”amzn”ID_LIKE=”rhel fedora”VERSION_ID=”2018.03″PRETTY_NAME=”Amazon Linux AMI 2018.03″HOME_URL=”

GLU.Engine – Performance-Level Settings

Where there is a particular requirement to provide higher levels of performance from the GLU.Engine it is recommended to adjust the Java JVM settings. 

The existing settings in the can be adjusted. 

Change {GLUENGINE-1.4-SNAPSHOT} to match the engine which is being used. 

The memory settings can be adjusted to reflect the size of the machine the GLU.Engine is deployed on i.e. 

-Xms1G -Xmx1G can be changed to  -Xms100m -Xmx100m (if the memory available means these settings need to be lower)

java -XX:+PrintGCDetails -Xloggc:gc.log -Xms100m -Xmx100m -XX:+UseG1GC -XX:MaxGCPauseMillis=250 -XX:+UseStringDeduplication -XX:G1HeapRegionSize=32 -XX:G1ReservePercent=15 -XX:InitiatingHeapOccupancyPercent=30 -XX:MetaspaceSize=100M -jar ./engine/GLUENGINE-1.4-SNAPSHOT.jar --spring.config.additional-location=./engine/config/appSetting.yml

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


8 CPU machine , leave this setting at 8

2 CPU machine, change this setting to 2, -XX:ConcGCThreads=2

6 CPU machine , change this setting to 6, -XX:ConcGCThreads=6

Default with out this setting will reflect 1 CPU.

GLU.Engine – Runtime Environment – Java

Runtime EnvironmentSpecification
JavaVersion 1.8 (Java 8)See install instructions in this link.

From release 1.9.17 GLU has embedded a set of performance optimised JVM settings into the GLU.Engine package. The default settings are aligned to analysis carried ou by GLU in the lab on on-going performance optimisation and load testing.

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

JVM Settings

To optimise CPU performance and memory utilisation of your GLU.Engine, a set of JVM Settings can be configured in the GLU.Engine settings dialogue box. These settings will be included in the GLU.Engine script. These settings should be refined to match the required settings for the environment which the GLU.Engine will run in. 

In the settings there are the settings for Garbage collection performance. 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.

DevOps Guide


The only 3rd party product used by GLU are 

– Java Version 1.8 

– A server to host the Java virtual machine (Docker/VM/server)

The GLU.Engine Server hosts the executable generated by the GLU.Console to provide integration. It takes the form of a .JAR file (i.e. Springboot Container). Each ‘Application’ equates to one GLU.Engine and each GLU.Engine can be deployed on its own Hardware as outlined below and depending on port values. 

This Hardware recommendation is provided as a baseline specification to be considered in parallel with the performance expectations. 

If there is an expectation of high or system performance, CPU & memory should be increased. 

To provide scale a GLU.engines can be scaled horizontally utilising a load balancer as part of the solution or a GLU.Engine setup as a Decision Maker to send transactions to a set of GLU.Engines running parallel. Please contact GLU support for more details on setting up these architectures. 

Server Specifications

GLU.Engine Server Specifications

GLU Engine Deployment Guidelines

GLU.Engine Deployment Guidelines

Monitoring Deployment Guidelines

GLU.Monitoring Deployment Guidelines

Logging Deployment Guidelines

GLU.Logging Deployment Guidelines

Engine APIs

GLU.Analytics or GLU.Engine APIS. Set of APIs exposed through the server port to provide data on the running GLU.Engine.

GLU.Engine APIs

Swagger web page

The swagger web page will be accessible through a web page on the following URL 

http://{URL for the GLU.Engine}:{serverPort}/swagger

For more information on understanding the swagger page please refer to Generate OpenAPI 3.0 (Swagger)

Deploying and running a GLU.Engine

A GLU.Engine can be deploy in the following ways 

  • A GLU.Engine deployed on a server.
  • A GLU.Engine deployed in docker container manager such as SwarmPit, Kubernetes docker desktop.

The diagram below describes how the GLU.Engines can be set up with 3rd party monitoring and logging analytic capabilities as well as an internal web page generated to show swagger definition for the APIs in the GLU.Engine. 


GLU recommends the use of Grafana on a separate server to monitor and provide alerts on data coming from the data produced by the GLU.Engine. 

Prometheus and node exporter can be used on the GLU.Engine server to gather and send the monitoring data to Grafana. 

For Logging GLU recommends Elastic Search and provides a configuration of filebeats to facilitate either pushing the GLU.Engine logs to ElasticSearch or to Logstash. 

Direct to ElasticSearch

Setup approach for logging where logs sent direct to ElasticSearch.


Setup approach for logging where logs sent direct to Logstash.

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