RES: [corda-dev] Bulk Performace


Franklin França - BluPay
 

Hi Meier.

Are you getting better results than listed in https://docs.corda.r3.com/sizing-and-performance.html ?

 

Thanks,

 

Franklin.

 

 

De: corda-dev@groups.io <corda-dev@groups.io> Em nome de Remo Meier via Groups.Io
Enviada em: quinta-feira, 10 de outubro de 2019 06:56
Para: corda-dev@groups.io
Assunto: Re: [corda-dev] Bulk Performace

 

Hi Franklin

Various different things:

- the bulk import job we try to optimize is bascially just a plain Java/Spring main application making use of Corda RPC.
- for test and production systems we have an ELK stack with metrics & tracing to see where we burn performance. it is integrated into all components as JVM agent.
- Locally for development we use JProfiler on our components and Corda. Currently, the focus lies here till the bottlenecks are gone.

Regards Remo

 

 


Remo Meier
 

Hi Franklin

> Are you getting better results than listed in https://docs.corda.r3.com/sizing-and-performance.html ?

I would say "different results" because the optimizations we are doing are bulk optimizations between nodes to gain very height throughputs. These optimization and Corda Enterprise would play well together for even better results. But our project is not there yet.

Our results are preliminary. And a comparison is difficult without more details in the official docs. Maybe even an official "benchmark cordapp" to test local installations for bottlenecks. For example, in the docs is a mix of Corda 3 and 4 numbers. Or not sure how many CPU core have been used for Figure 1. Given the numbers of Figure 3 I assume 64 cores, which is quite a beast of a CPU. Unfortunately, I cannot play with one of those :-)

There is a small update on our first results: first multiple node numbers. We have two Corda nodes with 2x4 cores in total giving 125 tps. The drop-off compared to single node performance has been rather mild whereas official number break-in by about 75%. Not suprising given the nature of the optimization and in-line with Figure 2. Currently the very limiting factor is the serialization layer. Maybe it is an issue on our side, maybe it is as expensive as it is or maybe in can be tuned further. If anybody has direct feedback on that, input would be welcomed. Otherwise I will take a shot at this the coming weeks with the hope to get rid of that bottleneck. Most likely new ones will pop up. One step at a time... I can then give more insights after. Currently it is still a bit of a side-project, but we are closing in on the desired numbers and may manage to exceed them.

Regards Remo