From cb0900a92e3ab3c2df9cfba344fcc99e076b9489 Mon Sep 17 00:00:00 2001 From: Victor Allombert Date: Wed, 5 Jun 2024 16:52:30 +0200 Subject: [PATCH 1/2] Benchmarks/RPC: add benchmark results --- devtools/benchmarks-tools/bench_RPS/README.md | 15 +++ .../benchmarks-tools/bench_RPS/results.json | 101 ++++++++++++++++++ 2 files changed, 116 insertions(+) create mode 100644 devtools/benchmarks-tools/bench_RPS/results.json diff --git a/devtools/benchmarks-tools/bench_RPS/README.md b/devtools/benchmarks-tools/bench_RPS/README.md index 0fa098066a36..42947987b08f 100644 --- a/devtools/benchmarks-tools/bench_RPS/README.md +++ b/devtools/benchmarks-tools/bench_RPS/README.md @@ -53,3 +53,18 @@ for kind in health header baking attestation; do done ``` + +# Results + +Previous values of this benchmark can be found in `results.json`. This +result comes from manual runs and is aimed to be updated manually. The +benchmarks were executed on the Octez recommanded hardware, which is a +GCP `n2-standard-4` virtual machine. +The json file is made of the following fields: +- kind: the RPC server that is tested (local or external) +- rpc: the RPC that is tested +- concurrency: the number of concurrent RPC requests allowed +- rps: the Request Per Second benchmark value + +We should consider having this automatized to get track of performance +regression, see https://gitlab.com/tezos/tezos/-/issues/7286 diff --git a/devtools/benchmarks-tools/bench_RPS/results.json b/devtools/benchmarks-tools/bench_RPS/results.json new file mode 100644 index 000000000000..fe7e38d2c62a --- /dev/null +++ b/devtools/benchmarks-tools/bench_RPS/results.json @@ -0,0 +1,101 @@ +{ + "date": "2024-06-05T12:00:00.000Z", + "value": [ + { + "kind": "Local RPC", + "rpc": "Health", + "concurrency": "1", + "rps": 4049 + }, + { + "kind": "Local RPC", + "rpc": "Health", + "concurrency": "10", + "rps": 5637 + }, + { + "kind": "Local RPC", + "rpc": "Header", + "concurrency": "1", + "rps": 4054 + }, + { + "kind": "Local RPC", + "rpc": "Header", + "concurrency": "10", + "rps": 5992 + }, + { + "kind": "Local RPC", + "rpc": "Baking right", + "concurrency": "1", + "rps": 706 + }, + { + "kind": "Local RPC", + "rpc": "Baking right", + "concurrency": "10", + "rps": 762 + }, + { + "kind": "Local RPC", + "rpc": "Attestation right", + "concurrency": "1", + "rps": 91 + }, + { + "kind": "Local RPC", + "rpc": "Attestation right", + "concurrency": "10", + "rps": 91 + }, + { + "kind": "External RPC", + "rpc": "Health", + "concurrency": "1", + "rps": 4309 + }, + { + "kind": "External RPC", + "rpc": "Health", + "concurrency": "10", + "rps": 6899 + }, + { + "kind": "External RPC", + "rpc": "Header", + "concurrency": "1", + "rps": 4294 + }, + { + "kind": "External RPC", + "rpc": "Header", + "concurrency": "10", + "rps": 6618 + }, + { + "kind": "External RPC", + "rpc": "Baking right", + "concurrency": "1", + "rps": 730 + }, + { + "kind": "External RPC", + "rpc": "Baking right", + "concurrency": "10", + "rps": 811 + }, + { + "kind": "External RPC", + "rpc": "Attestation right", + "concurrency": "1", + "rps": 91 + }, + { + "kind": "External RPC", + "rpc": "Attestation right", + "concurrency": "10", + "rps": 91 + } + ] +} -- GitLab From dfbb9494f02a67d1bb6abb929f51e7510c6e098e Mon Sep 17 00:00:00 2001 From: Victor Allombert Date: Wed, 5 Jun 2024 16:53:07 +0200 Subject: [PATCH 2/2] Doc: update documentation to advertize RPC benchmark framework --- docs/developer/rpc.rst | 33 +++++++++++++++++++++++++++++---- 1 file changed, 29 insertions(+), 4 deletions(-) diff --git a/docs/developer/rpc.rst b/docs/developer/rpc.rst index d7ab9cc644ba..d1761f2bac5b 100644 --- a/docs/developer/rpc.rst +++ b/docs/developer/rpc.rst @@ -5,10 +5,7 @@ The Octez node provides a JSON/RPC interface. Note that it is an RPC interface, and it is JSON based, but it does not follow the “JSON-RPC” protocol. It is not active by default and it must be explicitly activated with the ``--rpc-addr`` option. In that case, an RPC server -is started by the node. It is also possible to run an RPC server that -is external to the node, as a separate process, thanks to the -``--external-rpc-addr`` command. However, it is not recommended to use -``--external-rpc-addr`` as the external RPC server is not yet stable. +is started by the node. As an example, if you are not trying to run a public RPC node, but you just want to explore the RPC interface on your own, you would run: @@ -76,6 +73,34 @@ calls with their input/output. A useful tool to manipulate JSON is `jq `_. +Running the RPC server in a side process (experimental feature) +--------------------------------------------------------------- + +It is also possible to run an RPC server that is external to the node, +as a separate process. To do so, simply use ``--external-rpc-addr`` +(instead of ``--rpc-addr``) in the command lines. + +Thanks to this feature that is particularly suitable for service +providers, the node won't experience slowdowns on computationally +intensive RPC calls. This prevents the node from stopping +synchronization with its peers or becoming out of sync. Additionally, +performance is expected to be slightly increased in terms of requests +handled per second. A benchmark framework, that can be found in the +:src:`devtools/benchmarks-tools/bench_RPS/rps.sh` script of the Octez +repository, allows to run performance evaluations easily. Along to +this benchmark framework, former results are stored in the dedicated +:src:`devtools/benchmarks-tools/bench_RPS/results.json` file. + +In turn, this comes with an increased latency for RPCs related to +block injection, operation simulation or mempool operations. + +Thus, the ``--external-rpc-addr`` option is particularly suitable for +service providers, but should nod be activated in baking setups. + +.. warning:: + It is not recommended to use ``--external-rpc-addr`` yet, as the + external RPC server is still an experimental feature. + RPC versions ------------ -- GitLab