Date: Fri, 29 Mar 2024 01:29:36 +0000 (UTC) Message-ID: <1198849793.7.1711675776583@c00fee23c9e1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6_549115033.1711675776583" ------=_Part_6_549115033.1711675776583 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Introduce the harness.
It's a tool that allows running test scenarios against an rchain network= .
A grpc client extracted from the rchain project and bridged to gatling (= gatling.io).
https://github.com/lukasz-golebi=
ewski-org/rchain-perf-harness in the folder templater=
code>
It should become part of rchain soon.
Prerequisite: an rchain network running (e.g. one standalone node).
Three approaches to running the harness:
Ad. 1)
coop.r= chain.perf.DeployProposeSimulation
This simulation is configured in templater/runner/test/reourc=
es/appliaction.conf
rnodes= =3D["localhost:40401", "127.0.0.1:40401"]
sbt runner/gatling:test
Ad. 2)
coop.rchain.perf.ContinuousRunner
This is a typical Main
style app. behaves similar to t=
he above simulation but can be run
instead of teste=
d
.
The params are as follows:
#!/bin= /bash set -axe java -Dhosts=3D"$1" -Dpath=3D$2 -Dsessions=3D$3 -Dratio=3D$4 -Dloops=3D$5 -= jar ./runner.jar=20
Ad. 3)
coop.rchain.perf.Runner
object= Propose { def propose(session: Session)( client: ClientWithDetails): (Session, DeployServiceResponse) =3D { (session.remove("client"), client.client.createBlock(Empty())) } } object Deploy { def deploy(session: Session)( client: ClientWithDetails): (Session, DeployServiceResponse) =3D { val (_, contract): (String, String) =3D session("contract") .as[(String, String)] val d =3D DeployData() .withTimestamp(System.currentTimeMillis()) .withTerm(contract) .withFrom("0x1") .withPhloLimit(0) .withPhloPrice(0) .withNonce(0) (session.set("client", client), client.client.doDeploy(d)) } }
You can use these in any way.
There a myriad ways of setting up a network:
./scripts/p2p-test-tool.py -b -p 5 -i rchain/rno=
de:dev
assembly jar
java = -jar rnode-assembly-0.6.1.jar run -s --validator-private-key f7a9f1...9 --h= ost localhost
Main
(https://github.com/rchain/rchain/blob/dev/node/src=
/main/scala/coop/rchain/node/Main.scala)We encountered an issue with the contract:
contra= ct @"dupe"(@depth) =3D { if (depth <=3D 0) { Nil } else { @"dupe"!(depth-1) | @"dupe"!(depth-1)= | @"dupe"!(depth-1) | @"dupe"!(depth-1) | @"dupe"!(depth-1) | @"dupe"!(dep= th-1) | @"dupe"!(depth-1) | @"dupe"!(depth-1) | @"dupe"!(depth-1) | @"dupe"= !(depth-1) } } | @"dupe"!(5)
The scenario was as follows:
10 deploys, 1 propose, 10 threads running "at once", 100 loops. A networ= k of 5 rnodes.
The problem observed was Kamon Http client throwing exceptions. This was= most likely due to node running out of memory and becoming unstable.
A good starting point would be to reproduce, make sure it's the heap run= ning out and getting heap dumps.