Corda RPC通信。性能低下

Question

具有客户端通过RPC触发cordapp并等待结果的情况。

rpcConnection.proxy
.startFlow(::ImportAssetFlow, importDto)
.returnValue
.get(importTimeout /* 30000 ms */, TimeUnit.MILLISECONDS)

流正确触发并返回响应，但是处理流后响应缓慢的问题。在FlowLogic.call（）代码块的末尾，响应应该通过Artemis消息返回给客户端。 12秒后，结果将通过Corda Future返回给客户端。

在客户端上，通过RPCClientProxyHandler的调试lvl日志来检查该进程的工作方式：

2020-01-08 12:12:45.982 DEBUG [,,,] 78798 --- [global-threads)] n.c.c.r.internal.RPCClientProxyHandler   : Got message from RPC server RpcReply(id=fc317c4a-3de4-4936-b4c3-768b8b727245, timestamp: 2020-01-08T10:12:44.237Z, entityType: Invocation, result=Success(FlowHandleImpl(id=[16566124-f7d2-41cf-b3a4-f86846073632], returnValue=net.corda.core.internal.concurrent.CordaFutureImpl@58f8aa01)), deduplicationIdentity=e3f6d696-dea4-45b0-95b8-f9c0fe363a9f)
2020-01-08 12:12:45.986 DEBUG [,,,] 78798 --- [global-threads)] n.c.c.r.internal.RPCClientProxyHandler   : Got message from RPC server Observation(id=b3f0b064-6d82-4900-85e6-e70b7d00926a, timestamp: 2020-01-08T10:11:26.411Z, entityType: Invocation, content=[rx.Notification@b461fac0 OnNext Added(stateMachineInfo=StateMachineInfo([16566124-f7d2-41cf-b3a4-f86846073632], ***.workflow.asset.flow.ImportAssetFlow))], deduplicationIdentity=e3f6d696-dea4-45b0-95b8-f9c0fe363a9f)
2020-01-08 12:12:45.987 DEBUG [,,,] 78798 --- [global-threads)] n.c.c.r.internal.RPCClientProxyHandler   : Got message from RPC server Observation(id=12887a04-f22c-422d-b684-c679f137d66b, timestamp: 2020-01-08T10:12:45.979Z, entityType: Invocation, content=[rx.Notification@4c59250 OnNext Starting], deduplicationIdentity=e3f6d696-dea4-45b0-95b8-f9c0fe363a9f)
2020-01-08 12:12:58.603 DEBUG [,,,] 78798 --- [global-threads)] n.c.c.r.internal.RPCClientProxyHandler   : Got message from RPC server Observation(id=b83c15ca-9047-4958-a106-65165e5abfbd, timestamp: 2020-01-08T10:12:45.975Z, entityType: Invocation, content=[rx.Notification@e03cfa2d OnNext [B@2dceac3d], deduplicationIdentity=e3f6d696-dea4-45b0-95b8-f9c0fe363a9f)
2020-01-08 12:12:58.605 DEBUG [,,,] 78798 --- [global-threads)] n.c.c.r.internal.RPCClientProxyHandler   : Got message from RPC server Observation(id=b83c15ca-9047-4958-a106-65165e5abfbd, timestamp: 2020-01-08T10:12:45.975Z, entityType: Invocation, content=[rx.Notification@15895539 OnCompleted], deduplicationIdentity=e3f6d696-dea4-45b0-95b8-f9c0fe363a9f)

事件之间有很大的差距

• 12:12:45.987 OnNext Starting-消耗1k个对象的流的开始
• 12:12:58.603 OnNext [B@2dceac3d]-操作的实际结果。因此，返回响应的时间约为12.5秒。

根据Jprofiler Corda在约1.3秒内处理的流并将结果发送回去。

这种行为是什么原因，导致artemis消息的日志记录缓慢？

UPD：发现Corda具有挂起/恢复机制（检查点），用于将线程状态存储到磁盘，并在将来再次读取它并恢复该线程。net.corda.node.services.statemachine.FlowStateMachineImpl＃run会触发co.paralleluniverse.fibers.Fiber＃parkAndSerialize。似乎是消费者的时代之一。

非常感谢您

Answer 1

可能有多种原因：

1. JProfiler可能未正确报告流持续时间。其他性能分析工具肯定无法像Fibers那样进行停车，因为每次从挂起中恢复都看起来像一个独特的方法调用。我会在您的流程中添加一些日志记录，以检查实际需要多长时间。
2. 如果您从流程中返回非常大的结果（例如，大量的大对象），则通过RPC对其进行序列化和反序列化可能会花费相当长的时间。那么，您返回的结果是否很大？