1. Messages
  2. Private data logs in fabric version 2.0

Re: Private data logs in fabric version 2.0 #fabric #fabric-chaincode

Senthil Nathan
 

Hi,

   We compared the performance of both v1.4 and v.2.0 using public data, i.e., without collections. We have not observed any performance differences.

   Since the introduction of pvtdata feature, the gossip coordinator checks whether any transaction in a given block modified a collection's data. If any transaction does modify a collection's data, the coordinator would check for eligibility, i.e., whether the peer org is a member of the collection. If the peer org is a member, the coordinator fetches the missing pvtdata from either local transient store or remote peers. If transactions in a block have not modified any collection's data (as in your case), the coordinator wouldn't try to fetch it.

In v2.0, this part of the code got refactored and some additional logs such as the one you have mentioned above were added. Otherwise, there is not much change in the logic. It is surprising to hear that you notice a drop in performance. We will look at the log statements and convert them to either debug statements or put behind an if-then-else as appropriate.

To debug the performance drop, can you share the value of the following metrics for both v1.4 and v2.0?
  1. gossip_privdata_fetch_duration
  2. gossip_privdata_list_missing_duration
  3. gossip_privdata_pull_duration
  4. gossip_privdata_commit_block_duration
  5. gossip_state_commit_duration
Regards,
Senthil


On Thu, May 14, 2020 at 3:26 PM <susheeldighade@...> wrote:
Hello,
After the migration of our fabric setup from 1.4.4 version to 2.0, we have observed the private data logs getting appeared in the peer logs even though we are not using any private data collections in the chaincode. These logs weren't there for fabric 1.4.4 version. 

2020-05-07 12:36:42.909 UTC [gossip.privdata] prepareBlockPvtdata -> INFO 3664 Successfully fetched all eligible collection private write sets for block [3128] channel=mychannel

Also the block_and_pvtdata_commit latency has increased after the migration. Please clarify if there is any private data check for each transaction getting committed to the ledger in fabric 2.0 version. If so, is there any configuration by which this check can be bypassed.

We feel this private data activity is adding an additional latency in our TPS test results.

Join fabric@lists.hyperledger.org to automatically receive all group messages.