Let's talk about the benchmark tests to aesc_fsm_SUITE #1197


The original Link : https://github.com/aeternity/epoch/pull/1197

Two different timings are run:

A tight loop on a single channel, transfering 1 token back and forth 1000 times
Doing the same thing 100 times each in 10 concurrent channels
The timings appear as comments to the test cases (see below). mspt = milliseconds per transfer, tps = transfers per second.

Note that the Erlang client API is used, so the cost doesn’t include WebSocket termination and handling. Also, the cost of signing messages is included. Running 200 channels, the multi-channel test seems to become CPU-bound on my Core i7 Macbook Pro (2 cores with 4 hyperthreads each).

Guys,How do you look about this post?


Hey @imae.one and @zzy,

We’ve forwarded your question to our dev team and here is the response from @ulf.wiger, who ran the test:

It’s important not to read too much into those tests. The main purpose is to start having some tests that allow us to keep track of performance and scalability, so that we can quickly discover if some change has a significant effect in that area. Also, for the purposes of early warning, I wanted to check whether the performance seemed to be in the tens of transfers per second or in the hundreds.

The tests are also designed to be lightweight, so that they won’t cause timeout problems or long delays in the Continuous Integration environment. We need to run more accurate and thorough performance tests, but they should not be run automatically everytime we push a change.

Interestingly, I thought that the multi-channel test would take longer in the CI environment, but it clocked 995.5 tps – yay CircleCI! The single-channel test ran more slowly, but possible explanations could be that there are more, but slower, cores there than on my Macbook, or that more stuff is running in the background. It’s too simple a test to read too much into single data points.

Best regards,
The AE Team


@aeternity-team When I want to make a transaction. It take me about 9.8 second to create channel. I think this step is too long time. Unfriendly to a single transaction.


@Sven This is because the channel FSM is waiting for the create transaction to be confirmed by a minimum amount of blocks on top of the block where the create transaction was included. The minimum depth can be set in the channel create call, but it is a good idea to wait so that the channel isn’t lost in a fork.