Caliper generates reports of TPS issues encountered!!! 6Tps?

[Smy0521]

Caliper generates reports of TPS issues encountered
Pressure test 1000 trades 100tps
The first problem arose when the transaction was sent
Below the figure is the generated TPS report

The sync-request function is introduced in sending transactions
The success of the transaction is shown in the figure below.
{ code: '0000',
msg: 'exec successfully',
txid: '74ee9d9890ae45d687ac58cad26d07fb' }

Use the function request-promise introduced by asynchronous sending transactions
The blockchain network could not receive information if the transaction failed, as shown in the figure

Here is the TPS I tested manually

How to better position the way of the problem!!!
I think it's because the synchronization function affects TPS

[aklenik]

@zsh122958 I think we'll need more context. Especially about your user test module, since it can affect the precision of scheduling, and it's written by you :)

[Smy0521]

@aklenik
This is my test configuration file

invokeSmartContract Send a deal

[aklenik]

@zsh122958 As I see, you wrote your own adapter to support a new platform. In that case, most of the code that is running is your own code. The critical path is the following for Caliper:

rate controller => user test module => invokeSmartContract => rate controller => ...

You use 5 client processes to generate a 200TPS workload, which means 40TPS per client process. This means that the rate controller code needs to be executed at least every 24ms to keep this pace. If you use more client, then this number can be higher (20 client => 10 TPS per client => 100ms duration between rate controller calls).

General advice: don't use sync calls in this path. I think line 54 is your problem. It blocks the event loop of Node.js so the rate controller is not called quickly enough. You should use async calls instead (the code will hardly change with the async/await pattern).

[Smy0521]

Thank you very much!
I'm going to do it asynchronously.
This is the report graph received.

This is something that bothers me a lot, or is there a better way? I'm trying to locate the TPS problem

[Smy0521]

In the underlying database of blockchain, 5,000 pieces of data are received.

[shiningfrog]

@zsh122958 hello, now your tps result seems very good, could you advice me how you build your network? what's your configuration? what block chain you test? fabirc?

[Smy0521]

@shiningfrog
How are you
We're testing our own blockchain
There are still some problems with the test results at present, if the test is successful later.
We can communicate with each other.

[shiningfrog]

@zsh122958 ok, thank you! by the way, could you give some advice in how to improve the tps first? my tps is only 20+ in caliper(open.js).

[panyu4]

@zsh122958 ， the result shows the backend blockchain system throughput equals to the successful transactions' number. It is caused by original bug, and was fixed by PR #274 . You can use the newest version test it again.

[Smy0521]

@shiningfrog
I used synchronous transaction before, resulting in low Tps.
Try launching multiple local clients.

[aklenik]

@zsh122958 As @panyu4 suggested, try rebasing your code to the up-to-date Caliper version, it had some bugs fixed recently. It shouldn't affect your adapter code.

[Smy0521]

@aklenik
This is the latest version of my use of caliper.
Asynchronous commit is currently used.
The operation is as follows:

info: [bench-flow.js]:
r.create.max: 1551755287.142
r.create.min: 1551755277.155
r.final.max: 1551755287.145
r.final.min: 1551755278.087

[aklenik]

@zsh122958 Can you share the entire code file of your adapter (as GitHub gist)? The TPS is still shady in your report.

[aklenik]

Relating to a custom adapter implementation, closing it.