Simple Performance Test

In the IMC test modules/Apps for IMC a few stopwatches are included to be able to time Command and DataReady calls. The result is written directly in the module/App output window.

Its implemented both in the .Net 6+ sample IMC modules/apps and in the Noah 4 IMC2 sample modules.

Get Coupler Codes and Clear Curve Commands has Stopwatch included in the IMCClient.

All tests have been performed on a developer PC

...

Image Modified

Dataready(String[]) and Request new Target has Stopwatch in the IMCServer.

...

...

To simulate live data from a REM module via DataReady the button Start Measurement in the IMCClient samples will send a command to the IMCServer that will as fast as possible in separate thread send 100 curves one by one where all measurement points are filled out. The time each call takes is logged in the IMCServer output window. Average time for call in calculated and written.

Image Removed

Performance result on a fast developer PC

...

Simple Performance Test Results

...

Comments:

The following factors make the REST interface slower especially Command. In previous the .NET 4 implementation, there is a direct connection between IMC Client and Server which make every call happen at once.

In the REST implementation the following happens slows performance in Command and DataReady calls.

Module makes an object (e.g. IMC command object) with data and sends a Command.

The Proxy first serialize the data object (the module process) when it leaves the module and then de-serializes it back to an object in the proxy itself. (The proxy process)

Then the data object is send through a direct connection form one proxy (IMCClient) instance to another (IMCServer) like previous IMC connection in Noah 4. This happens at once.

Then the Proxy sends an event to the IMCServer module again first serializing and de-serializing data.

Now the module (IMCServer) holds the original data as it was send from the client.

Now meanwhile the proxy waits for the module (IMCServer) to post the result of the data. (The proxy first check at 2 ms and then every 10 ms for the result)

Now the module post the command result which has to be serialized and de-serialized in the proxy.

...

• Serializing and Desalinizing which happens two times between two .Net 6+ modules (HTTPS line in the diagram)

• Converting Command and DataReady calls to events to receiver from the IMC Client/Server-Proxy.

For Command calls there is an extra time consuming factor due to the fact that a result must be returned.

When the IMCServer receives a Command event then it has to make a call back to IMC Client/Server-Proxy. The proxy is waiting for this call before the Command call can return.

For DataReady its much more simple and faster since there is no return value.

The is only to times Serialize/De-serialize.

Recommendation:

Seen from a performance perspective its it's recommended to use Command only to “activate“ the IMCServer and tell it what it should do. Don't use it to get a lot of Data.

We recommend that DataReady is used to send the actual data.

Stress test

Stress Test Setup - To simulate live data from a REM module

The IMCClient samples will send a command (Button Start Measurement) to the IMCServer. The IMCServer will respond with DataReady with 100 curves where all measurement points are filled out. The curves will be sent in a separate thread, one by one as fast as possible. The time each call takes is logged in the IMCServer output window. The average time for calls is also shown in the output. The Average time for 100 curves in our test was 12 ms per curve.

Stress Test Results

...