Interlok JMS performance samples. | Interlok Documentation

Sample JMS bridging performance.

While performance will vary greatly with each environment never being truly equal, this document will share performance statistics generated from a set of JMS bridging tests run from an AWS deployment. This is Interlok acting in a single-threaded manner using a StandardWorkflow or similar and is designed to expose the performance characteristics based on changing Interlok configuration. No other tuning was done for the various components; this means there was no JVM tuning of interlok or changing the default behaviour of the various messaging providers.

Environment.

Unless otherwise stated all deployed containers are AWS m5.large and all instances are deployed to the eu-west-1 region.
Five separate container instances have been used to host each of the following;

Interlok
Solace
WebsphereMQ
ActiveMQ
Prometheus / Grafana

AWS-Environment

Interlok

Interlok 3.11 installed onto Linux running Azul Zulu Java 8u265b11.

Solace

In place of an actual appliance we are using the Solace published AMI version 9.6.0.38.

WebsphereMQ

We have taken the WebsphereMQ developer edition version 9.1.5 and installed directly into AWS standard Ubuntu instance.

ActiveMQ

For ease of install we have opted for the Websoft9 ActiveMQ AMI version 5.16

Prometheus / Grafana

Very simply we have installed both Prometheus and Grafana via their docker images;

We simply then point Prometheus at Interlok to periodically scrape metrics.

The Tests

All software mentioned above are stock installations with no tuning for performance or otherwise.

Each test run will simply use Interlok to bridge 75,000 messages, each 2kb in size, from one message vendor to another. Each test will demonstrate a particular API, technology or configuration difference.
Considering the producer is usually the slowest part of a message bridge, we are including the average time each producer takes as well as the pure number of messages moved from one vendor to another.