clients in fabric-ccp.yaml file

[quangtdn]

Hi there,

I want to ask about the clients specified in fabric-ccp.yaml files. As I see, the clients that Caliper uses to run the benchmark are those specified in the config.yaml file (with type local or Zookeeper). Then what are those clients specified in fabric-ccp.yaml? In the fabric.yaml files, there is actually no specification for clients.

Thank you.

[houqinghui]

@quangtdn Maybe, @aklenik can answer you.

[aklenik]

@quangtdn Sorry for the late response. Here's the glossary (that we'll need to add to the documentation as well):

• Caliper workload generator client:
  These clients are Node.js processes that the "master" Caliper process spawns to generate high TPS workloads. Think of them as Node.js "worker threads." They're either spawned locally, or on a remote machine using Zookeeper.
• Fabric clients:
  These are the actual users of the Fabric network, each with its own identity (cert + signing key). They invoke transactions or queries, basically interact with the Fabric network. The Fabric-CCP network configuration lists these clients/users with a unique name, so you can reference them in your user callback by name, and the transaction will be sent using that identity.

TL;DR;
In the round config file, think of those clients as Caliper slave processes, while the network config file contains the actual clients/users of the network (user 2 of org 3 for example).

Hope this clarifies it a bit. We'll create a glossary once we aggree on the terminology :)

[quangtdn]

@aklenik
Let say we have M Caliper clients and N Fabric clients.
If I specify the transaction rate (in the rateControl of config.yaml) to be 100 tps, then what should be the real transaction/send rate that each of the N Fabric clients would send?

Should 100tps mean that the total transaction/send rate of all N Fabric clients is 100tps?
Or it means that each of the N Fabric clients has send rate 100tps, so the total send rate is 100N tps.
Or each of the Caliper clients generates a workload with send rate 100tps, resulting a big workload 100M tps that would be then divided evenly among the N Fabric clients.

I am sorry as I find it a bit confused.

Thank you very much for your clarification.

[aklenik]

@quangtdn
Let M=10 and N=6 (3 clients per org, with 2 org).

The two client concept is totally orthogonal to each other. A 100TPS load setting will be distributed among the 10 Caliper clients, so each Caliper client will generate a 10TPS load. This means that your run function in your user module will be called approximately in every 100ms.

In this run function, you call the invokeSmartContract function of the adapter. The CCP adapter accepts a settings argument, in which you can specify (by name) which Fabric Client should send the transaction:
https://hyperledger.github.io/caliper/docs/Fabric_Ccp_Configuration.html#the-run-callback

So it's your task to decide which Fabric client should invoke a specific transaction (this is a business logic detail). Right now you can't really assign Fabric Clients to Caliper Clients, since the Caliper Client index is not passed to the user module's init function. But it'll be passed soon, and then you can implement arbitrary logic that map between the two clients:

• Caliper Client 1 will invoke transactions in the name of Fabric Clients user1 and user1
• Caliper Client 2 will invoke transactions in the name of Fabric Client user2
• etc...

[quangtdn]

@aklenik Thank you for your clarification.
My very last questions to understand this clearly:

1. So the total transaction rate that the blockchain system receives from this benchmarking is 100TPS. Is it right?
2. For now, we cannot control the Fabric clients, which is fine actually, but Caliper will distribute the 100TPS send-transactions among these Fabric clients. Is it true?

Thank you!

[aklenik]

@quangtdn

1. Yes, the total rate is what you define in your round config file, 100TPS in this case.
2. No. If you don't specify the Fabric client name (e.g., client0.org1.example.com) in invokeSmartContract's setting (invokerIdentity), then the first identity in your config will be used. This is just a convenience default, you should always specify the invoker for a real test, since it usually matters.
   https://hyperledger.github.io/caliper/docs/Fabric_Ccp_Configuration.html#invoking-a-chaincode

[quangtdn]

Oh thank you @aklenik ! Your explanation does help much.
It seems that I missed that part in the documentation.