为什么接收调用和实际执行方法之间有这么长的延迟?

发布于 2025-01-12 20:58:26 字数 1137 浏览 1 评论 0原文

在此日志中,您可以看到收到调用和执行之间大约有 18 秒的时间。

org1peer0_1  | 2022-03-09 17:31:01.797 UTC [peer.chaincode.dev-peer0.org1.odins.com-GuardianSC1-86eed1b224916b39f365986d78daa728b34b4302900b7823223838e2bd9579a1] func2 -> INFO ac9ca1 17:31:01:796 INFO    org.hyperledger.fabric.contract.ContractRouter processRequest                    Got invoke routing request       
org1peer0_1  | 2022-03-09 17:31:18.986 UTC [peer.chaincode.dev-peer0.org1.odins.com-GuardianSC1-86eed1b224916b39f365986d78daa728b34b4302900b7823223838e2bd9579a1] func2 -> INFO ac9ca2 17:31:01:797 INFO    org.hyperledger.fabric.contract.ContractRouter processRequest       Got the invoke request for:METHOD [reallybigstring]

我正在使用一个订购者和一个组织以及一个同行。 docker 版本上的所有内容: hyperledger/fabric-peer:2.0

On the chaincode I'm using:
    compileOnly 'org.hyperledger.fabric-chaincode-java:fabric-chaincode-shim:2.2.+'
    implementation 'com.owlike:genson:1.5'
    testImplementation 'org.hyperledger.fabric-chaincode-java:fabric-chaincode-shim:2.2.+'

最后,作为该方法的参数,我传递了一个大约 20.700 个字符的字符串。除此之外,我可以说,使用较小的字符串,时间会减少。

On this logs you can see there are like 18 seconds between the call received and the execution.

org1peer0_1  | 2022-03-09 17:31:01.797 UTC [peer.chaincode.dev-peer0.org1.odins.com-GuardianSC1-86eed1b224916b39f365986d78daa728b34b4302900b7823223838e2bd9579a1] func2 -> INFO ac9ca1 17:31:01:796 INFO    org.hyperledger.fabric.contract.ContractRouter processRequest                    Got invoke routing request       
org1peer0_1  | 2022-03-09 17:31:18.986 UTC [peer.chaincode.dev-peer0.org1.odins.com-GuardianSC1-86eed1b224916b39f365986d78daa728b34b4302900b7823223838e2bd9579a1] func2 -> INFO ac9ca2 17:31:01:797 INFO    org.hyperledger.fabric.contract.ContractRouter processRequest       Got the invoke request for:METHOD [reallybigstring]

I'm using one orderer and one org with one peer. Everything on docker version: hyperledger/fabric-peer:2.0

On the chaincode I'm using:

    compileOnly 'org.hyperledger.fabric-chaincode-java:fabric-chaincode-shim:2.2.+'
    implementation 'com.owlike:genson:1.5'
    testImplementation 'org.hyperledger.fabric-chaincode-java:fabric-chaincode-shim:2.2.+'

And, finally, as parameter of the method I'm passing a string with about 20.700 characters. In addition to this, I can say that with a smaller string the time is reduced.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

酒废 2025-01-19 20:58:26

我认为这不是调用函数的执行时间。

处理字符串参数的时间是处理时间。

在两个日志之间,只有“stub.getStringArgs().size()”

private Response processRequest(final ChaincodeStub stub) {
    logger.info(() -> "Got invoke routing request");
    try {
        if (stub.getStringArgs().size() > 0) {
            logger.info(() -> "Got the invoke request for:" + stub.getFunction() + " " + stub.getParameters());
            final InvocationRequest request = ExecutionFactory.getInstance().createRequest(stub);
            final TxFunction txFn = getRouting(request);
            logger.info(() -> "Got routing:" + txFn.getRouting());
            return executor.executeRequest(txFn, request, stub);
        } else {
            return ResponseUtils.newSuccessResponse();
        }
    } catch (final Throwable throwable) {
        return ResponseUtils.newErrorResponse(throwable);
    }
}

I think this is not invoke function's execution time.

It is processing time that processes your string argument.

Between both logs, It only 'stub.getStringArgs().size()'

private Response processRequest(final ChaincodeStub stub) {
    logger.info(() -> "Got invoke routing request");
    try {
        if (stub.getStringArgs().size() > 0) {
            logger.info(() -> "Got the invoke request for:" + stub.getFunction() + " " + stub.getParameters());
            final InvocationRequest request = ExecutionFactory.getInstance().createRequest(stub);
            final TxFunction txFn = getRouting(request);
            logger.info(() -> "Got routing:" + txFn.getRouting());
            return executor.executeRequest(txFn, request, stub);
        } else {
            return ResponseUtils.newSuccessResponse();
        }
    } catch (final Throwable throwable) {
        return ResponseUtils.newErrorResponse(throwable);
    }
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文