Performance

File size: The kernel is only 1.3 MByte in size and therefore very fast to load. One consequence of the small size and significant asynchronicity is the rapid startup of the node. A central system node, incorporating various central registries and TCP servers, launches in approximately 200 ms. This is achieved even though about 400 dependency resolution jobs are executed at startup.; Microservices are usually only a few Kbytes in size. They are therefore loaded very quickly. There is no overhead (web server etc.). One node can load hundreds of services.; The entire network can be rebooted within a few seconds.
Messages: Messages are streamed and not parsed. This means that no JSON or XML is used. This gives you an advantage in terms of speed and resource consumption.
Message size: Messages vary in size depending on what they are transporting. Simple notifications are smaller than 100 bytes. Example: All messages to display the Swing application “UserManger”, including the description of the main dialog, together comprise about 40 KBytes.; A simple flag in the message header ensures automatic compression of the payload, which further reduces the message size, especially when transporting texts.
Open TCP channels: Messages are transported between nodes over open TCP channels. This eliminates the need to establish a connection with a security handshake. Communication via open channels between nodes ensures very short latency times. This allows you to easily and conveniently use services across multiple applications, maintaining and deploying them separately from the applications.
Asynchronous messaging: All messages in nyssr.net are asynchronous. There is no waiting for a response at any point.
Distribution: Distributed systems can perform tasks faster than centralized systems by distributing the workload across multiple nodes. This reduces the time required to perform tasks and increases the overall efficiency of the system.

Throughput using an example

Try out the “Getting started” project. In this project, we create a service that sends ping messages to targets in other nodes and waits for the response. As soon as the response is returned, a new ping is started. There is only one message per ping, either on the outward journey or on the return journey.

In our demonstration environment, 5 nodes are started. Our getting-started service is started on the moon node.

The following console output shows pings starting from moon to sun, ceres, venus and mercury. You can clearly see that more hops also require more time. Nevertheless, the throughput for 3 hops from moon to venus is over 4300 messages per second (with simultaneous pings to sun, mercury and venus), i.e. a quarter of a millisecond per message.

The values were determined after all nodes were started on the same computer. For nodes on different machines, the distance-dependent times of the TCP routes are added.

4 sequential ping commands in the console

Here is the same picture with one active ping (moon --> sun).

1 sequential ping commands to neighbor node

This means that in our test, a request from the node moon to a microservice on the neighboring node sun, including the response takes just 0.14 milliseconds or 140 microseconds! A REST request is many times slower.

A ping to a target in a different namespace of the same note results in significantly higher rates per second:

1 sequential ping to same node but different namespace

A ping to a target in the same namespace of the same note results in even higher rates per second:

1 sequential ping to same node and same namespace

Here is a snapshot of the Windows Task Manager (German Windows 11, AMD Ryzen 9 5950X 16-Core Processor). The load is distributed well across the machine's cores. In a productive environment, there are of course many more namespaces/threads than in the demonstration environment.

By the way: The web application is not slowed down by the running test, as the message queues are all empty. With 4 simultaneous pings, only 4 messages are in transit at the same time.

The ping message must not be confused with the low-level pings for monitoring the TCP links between the nodes. This ping message is a high-level message and is actually sent to individual targets. To simulate the message IO, a payload is also sent. It should also be kept in mind that the asynchronous throughput (when we are not waiting for the message to return) is considerably higher.

Conclusion

These properties ensure that high performance is achieved for applications even with low bandwidth. This applies to web applications as well as server-based Swing applications.