Authors: Sam Yuan (Yi Yuan) and Haris Javaid (Haris Javaid)
This article summarises offline discussions between PSWG members in order to document the current activities and long term goals of PSWG. We welcome any kind of contributions to this article and any projects mentioned here. The performance sandbox project below is going to be the spotlight of this year's activities. In future, PSWG plans to discuss technological contributions in greater detail with other groups in Hyperledger community, and to offer guidance on standard procedures and emerging best practices for evaluating blockchain performance.
Please join us in the Performance and Scale Working Group to get involved and for subsequent updates on our progress.
Introduction
Infra
We found k8s is becoming a standard infrastructure for software and which means we are able to have a vertical digram for how people deploy blockchain system.
Blockchain applications typically involve multiple layers of infrastructure as depicted below. At the lowest layer is the hardware infrastructure which provides the basic compute, memory and network resources to deploy a distributed system. Typical example includes multi-core servers with acceleration cards (GPUs, FPGAs, etc.), large memories and hard disks. The next layer involves automated tools that enable easy creation, deployment and management of various nodes inside a distributed system. A popular example here is Kubernetes (k8s) which allows easy creation, deployment, scaling and management of containers (e.g. dockers) in a datacenter environment. The blockchain layer involves setting up the underlying blockchain system or platform such as Hyperledger Fabric, and configuring it according to the needs of the blockchain application. The top level involves creating and deploying the application on the blockchain platform, e.g. smart contracts, application data model, GUI, etc.
This article covers how we can measure and continuously observe performance of a blockchain application and/or system when deployed in k8s environment, and introduces some performance improvement techniques.
Performance Monitoring and Observability
TODO Yi YuanAs figure above, in the following parts of this article, we are going to discuss blockchain performance and scale related question base on k8s and hardware area. As most k8s based tool as observability related tools also support no k8s deployment, hence we don't specific case for non k8s deployment. You are free and able to use those tools to adopt with your no k8s deployment.
Performance
Learn from CNCF paper, we can give a steps for blockchain adopt with cloud native and with observability's help to improve performance or handling anything related with performance.
...
Taking Hyperledger Fabric as an example:
1. Hyperledger Fabric on k8s(a short description for fabric operators)
There lots of project deploy Hyperledger Fabric on k8s, for example, https://github.com/hyperledger-labs/fabric-operator, even so far performance sandbox still working with shell script based k8s-test-network, but as a long term plan, we will adopt performance sand box with fabric-operator.
2. Hyperledger Fabric with observability
Hyperledger Fabric makes metrics long before, as ref
now a days, with rfc community schedules supporting opentelemetry.
3. Hyperledger Fabric performance testing tools on k8s with observability.
Here we take Tape as sample.
Tape is a Simple Traffic Generator for Hyperledger Fabric, it takes 3 steps from zero to integrated deployment on k8s with observability.
3.1 distributed
To make test harness support distributed, you need to split traffic generator and monitoring client. Making them able to run in split mode.
3.2 metric
For test harness, we are able to expose metrics for performance research usage. For example, when we want to calculate latency, there is one way to make a latency report at test harness instead of tracing metrics for each node.
3.3 tracing
You are able to use labels and grpc options to support distributed tracing among test harness.
4. dashboard
...
In the test data with about 10k transaction, in 1k block.(as 10 transactions in one block following configuration.)
We can find the ledger blockchain height rate as block height/time(as rate) and among the duration in time zone. Some how it shows the throughput for transactions base on block height. Or we are able to use transactions in specific channel. As Business transaction per channel, chaincode shows. How the transactions increase during the time.
Performance Improvements with Custom Hardware
to be finish by TODO Haris Javaid
...
Scaling Performance Observability and Improvements
Just answer one single question, how to testing a system with thousands of nodes?
It seems that we got one answer learn from CNCF on a recording for kubecon.
As we test scaling with mock system, for detail:
When we deep dive blockchain node, we are able to split features or modules inside a node.
- internal features
In this area, when we scale up size of blockchain system, it just linear increasing.
for example, an engine to running a specific chain code. For most blockchain system, the node should be able to running chaincode for execution and business logic.
However, for scale up, it just linear increasing the resources.
Unfortunate our research environment is resource limited, hence to do the research or just simulate a large size of network, we need to mock this part of features in our mock system for example making it always return success for any response.
- external communication features
In this area, when we scale up size of blockchain system, it is the key features been impacted by size.
for example, most of blockchain system relay on p2p network or gossip network.
With scale up the sizing of blockchain network, the performance of p2p network will impact the performance of blockchain system.
Auth
Sam Yuan(Yi Yuan )
to be update by Haris