最近我们在为我们的应用程序解决一个性能问题时遇到了麻烦,代码最初基于M13版本的Corda教程代码构建,我们遵循Corda的版本,现在它更新为V2.0。业务很简单,甲方在表格中上传一份包含某些元数据的合同文件,然后将此交易发送给乙方,我们在验证功能中定义了一些简单的条件,所以通常交易将在没有任何人工操作的情况下完成。但是这个过程如果我们在当地环境中做到这一点,它需要大约3个secondes(一个2.9M附件),但是当我们将它部署到我们的开发环境,H2被托管在CorDapp的单独服务器中时,它总是需要15个用一个公证节点完成-20秒。
我们尝试启用H2跟踪日志功能,从日志中,我们发现执行了165条SQL语句,包括114条选择,31条插入,16条删除,2条更新和2条更改。我们的流程与教程的代码大致相似,除了接受器流,我们有与启动器流类似的验证功能,我们有附件,但教程没有。
使用相同的方法,我在Corda示例代码上执行了一个创建IOU事务,该代码基于V1.0(因为没有V2.0示例代码,因此我只能在V1.0上执行),因为该事务,执行了118个SQL语句,包括74个选择,28个插入,14个删除和2个更新。
还有很多“SET LOCK_MODE”和COMMIT,检查点被删除并频繁插入。因此,我们希望得到您对以下问题的评论,请对此提出帮助。感谢。
这些如此多的SQL执行对于事务是否合理,这些必须要发生才能完成一个事务? 由于我们可能无法理解每个SQL执行的目的是什么,因此您是否有任何建议我们应该为下一步找到它的根本原因?交易15-20秒是否正常,因为我们在不同的服务器中分别托管H2数据库和公证人?我们的CorDapp(甲方,乙方和公证人),H2数据库分别托管在Azure VM上。
答案 0 :(得分:0)
Corda的工作重点是功能性而非性能。在数据库和其他地方有许多性能改进,将在未来的版本中实现。
但是,交易没有理由花费15-20秒。
您运行交易的次数是多少?我问,因为每次节点看到一个新的附件作为事务的一部分时,它会缓存它并存储它以供以后参考。这意味着只需要通过线路为第一个事务发送大附件。如果您发送10个引用相同附件的交易,则只会在第一次下载,而其他9次会更快。你有没有观察到这些改进?