Hyperledger Fabric nodejs sdk性能问题

时间:2018-05-03 17:51:09

标签: node.js hyperledger-fabric

使用Hyperledger fabric node.js sdk时,我遇到了性能问题。

当我向sdk发出调用请求并使用以下代码消耗链代码给出的响应时

var proposalResponse = results[0];
            var proposal = results[1];
            let isProposalGood = false;

            if(proposalResponse
                && proposalResponse[0].response
                && proposalResponse[0].response.status === 200){
                    isProposalGood = true;
                    var res = JSON.parse(proposalResponse[0].response.payload.toString());
                            res.event_status = 'VALID'
                            resolve(res);
                }else{
                    reject(createErrorResponse(proposalResponse[0].message,500))
                    return
                }

api在50ms内响应,你可以看到下面的截图: enter image description here

但是,当我等待orderer使用以下代码确认交易时:

if (code === 'VALID'){
                            //get payload from proposal response
                            var res = JSON.parse(proposalResponse[0].response.payload.toString());
                            res.event_status = 'VALID'
                            resolve(res);
                        }else{
                            var return_status = createErrorResponse("Transaction was not valid", 500);
                            return_status.tx_id = transaction_id_string
                            reject(return_status)
                            return
                        }

需要近2500毫秒才能回复,因为你可以看到下面邮递员的截图:

enter image description here

如果我错了,请纠正我

我知道这需要时间,因为orderer确认了交易并提交到ledger。但是,如果orderer同意交易并投入ledger,您认为我们应该继续。如果是,那么响应需要2.5秒(网络在同一台机器上的本地机器和sdk上的docker上运行)这是一个性能问题。

如果将数据写入链码并且之后订单者拒绝将交易写入分类账,会发生什么?

任何帮助将不胜感激

2 个答案:

答案 0 :(得分:1)

  

订货人确认交易并提交到分类账。

订购服务的任务(顾名思义)仅按渠道按时间顺序对收到的已批准交易进行排序,然后将其发送给渠道中的所有同行。订货人实际上并未将交易提交到分类账。

提交者同行。提交是一个计时过程,因为所有对等方都验证了块内的所有事务,以确保满足认可策略,并确保读取集变量的分类帐状态没有变化,因为事务生成了读取集执行。块中的事务被标记为有效或无效。然后,每个对等体将块附加到通道的链,并且对于每个有效的事务,写集被提交到当前状态数据库。 发出一个事件,以通知客户端应用程序事务(调用)已被不可变地附加到链中,以及通知该事务是否已经过验证或无效。

因此,在了解Transaction Flow中的所有这些细节之后,应该注意客户端应用程序不应该等待订货人收到的响应。相反,它应该只是请求订购者交付认可的交易,并且应用程序应该订阅同行发出的事件,以便它应该知道或被告知交易实际上是在渠道链中不可变地提交的。

您可以在Fabric Node SDK docs中获得有关活动订阅的进一步帮助。

  

如果将数据写入链代码并在此之后会发生什么   orderers否认将交易写入分类账?

这是不可能的,因为只有当通过来自背书人对等方的适当认可(由认可政策指定)验证交易并最终传递给提交者对等方以在链中附加新值时才将数据附加到链上。并更新世界国家。数据仅在通过所有验证后写入链中,因此订货人永远不会否认数据中所做的更改。

答案 1 :(得分:0)

我发现了造成此延迟的另一个原因。

batchtimeout中的configtx.yaml变量设置为2秒。因此它将进行处理,然后等待2秒钟,然后切割一个块。因此,写操作大约需要2.5秒。