CN110580206A

CN110580206A - Method, medium and control device for pressure testing of a blockchain system

Info

Publication number: CN110580206A
Application number: CN201910868276.4A
Authority: CN
Inventors: 陈小云; 庄伟铭
Original assignee: Shanghai Insurance Exchange Ltd By Share Ltd
Current assignee: Shanghai Insurance Exchange Ltd By Share Ltd
Priority date: 2019-09-16
Filing date: 2019-09-16
Publication date: 2019-12-17
Anticipated expiration: 2039-09-16
Also published as: CN110580206B

Abstract

A method for pressure testing of a blockchain system, comprising: deploying accounting node modules, consensus node modules and application programming interface server APIServer modules in initial quantity on a single server according to initial configuration parameters of a block chain; performing multiple rounds of tests on a block chain deployed on a single server based on a contract through an APIServer module, wherein a billing node module is tested in each round of tests concurrently, and adjusting the concurrency number for each round of tests until the concurrency number basically saturates the system resource utilization rate of one of the billing node module, the consensus node module and the APIServer module; and determining the proportion between the number of accounting node modules and the number of consensus node modules for a typical stress test scene based on the system resource utilization rate of each module when the system resource utilization rate of the module is basically saturated, and determining the occupation relationship of each module to a server based on the multi-core utilization rate of each module to the CPU detected in the multi-round test.

Description

Method, medium and control device for pressure testing of a blockchain system

Technical Field

The present disclosure relates to a method, computer-readable medium, and control device for pressure testing of blockchain systems, particularly allied chain systems.

Background

In recent years, the technology relating to blockchains has been rapidly developed. A blockchain system has been developed for use in various fields. A blockchain may generally represent a distributed, decentralized network database system, where transactions occurring over the blockchain involve the participation of all nodes on the blockchain.

To better deploy the blockchain in a practical implementation, the blockchain system needs to be tested, in particular to be stress tested. Therefore, a method for quickly building a pressure test scene of the blockchain system and performing pressure test in the scene is needed.

disclosure of Invention

The present disclosure provides a method, computer readable medium, and control apparatus for pressure testing of a blockchain system.

According to an aspect of the present disclosure, there is provided a method for pressure testing of a blockchain system, comprising: deploying accounting node modules, consensus node modules and application programming interface server APIServer modules in initial quantity on a single server according to initial configuration parameters of a block chain; performing multiple rounds of testing on a blockchain deployed on a single server based on contracts via an APIServer module, wherein one accounting node module is tested concurrently in each round of testing, and adjusting a concurrency number for each round of testing until the concurrency number substantially saturates system resource utilization of one of the accounting node module, the consensus node module, and the APIServer module; and determining the proportion between the number of accounting node modules and the number of consensus node modules for a typical stress test scene based on the system resource utilization rate of each module when the system resource utilization rate of the module is basically saturated, and determining the occupation relationship of each module to a server based on the multi-core utilization rate of each module to the CPU detected in the multi-round test.

According to another aspect of the present disclosure, there is provided a computer-readable medium having stored thereon computer-executable instructions that, when executed by a processor, cause the processor to perform the method as described above.

According to yet another aspect of the present disclosure, there is provided a control device for pressure testing of a blockchain system, the control device comprising a memory storing computer executable instructions and a processor, the computer executable instructions when executed by the processor cause the device to perform the method as described above.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments of the disclosure and together with the description, serve to explain the principles of the disclosure.

Fig. 1 is a schematic flow diagram of a method for pressure testing of a blockchain system according to the present disclosure;

FIG. 2 is a schematic diagram of testing a blockchain deployed on a single server in accordance with the present disclosure;

FIG. 3 is a further schematic flow chart diagram of a method for pressure testing of a blockchain system according to the present disclosure;

FIG. 4 is a schematic diagram illustrating a blockchain architecture employed by a test example in accordance with the present disclosure;

FIG. 5 is a schematic diagram illustrating an exemplary test system employed in accordance with a test example of the present disclosure;

Fig. 6 is an exemplary configuration diagram of a computer device in which embodiments according to the present disclosure may be implemented.

Detailed Description

Preferred embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. Details and functions not essential to the present disclosure are omitted so as not to obscure the understanding of the present disclosure.

Note that like reference numerals and letters refer to like items in the figures, and thus once an item is defined in one figure, it need not be discussed in subsequent figures.

In this disclosure, the term "blockchain" includes, but is not limited to, techniques related to distributed storage, point-to-point networks, consensus mechanisms, encryption algorithms, and the like. The term "federation chain" or "federation chain" generally refers to a blockchain built by multiple organizations or enterprises in the form of a federation between which trust and consensus mechanisms are established through contracts or other forms, the building block and linking functions are limited to federation participants, and access rights can be opened to the outside in a restrictive manner. In particular, the techniques of this disclosure are typically applicable to allied chains, but the techniques may also be applicable to other types of blockchains, such as public and private chains.

As already introduced in the background section, blockchains have a distributed, decentralized feature, and transactions occurring on blockchains involve the participation of all nodes on the blockchain. The nodes on the blockchain typically include, for example, consensus nodes and service nodes. The consensus node, for example, runs a consensus algorithm so that it participates in block creation if the entire block chain agrees on the blocks. The service node may be, for example, the node that actually initiates a transaction on the blockchain, and may have different names under different blockchain architectures. In the present disclosure, a block chain architecture of a super book is taken as an example for explanation, and under the architecture, a service node is generally referred to as a billing (peer) node. In the description below herein, the term accounting node is used to denote a service node. It is noted that the techniques of this disclosure may also be applied to blockchains of other architectures, and the term "accounting node" is intended to mean a service node initiating a transaction on a blockchain as distinguished from a consensus node and is not intended to define a blockchain architecture.

The inventors of the disclosed technology have noted in particular that for blockchain systems, there may be bottleneck modules that affect their performance (e.g., number of TPS transactions per second). When the processing power of the bottleneck module is saturated, the performance of the blockchain system may remain saturated even if the number ratio of other modules and/or nodes (e.g., consensus node and accounting node) is changed. Therefore, there is a need for a method that can determine the bottleneck module that causes the performance bottleneck of the blockchain system, and the proportion of the number of other modules and/or nodes when the module is saturated, so as to provide a reference for the deployment of the actual blockchain system.

Stress testing generally refers to initiating large concurrent tests on nodes in a system with normal system resources, mining the number of transactions per second, TPS, and/or the number of queries per second, QPS, of the system.

Conventionally, a stress test method similar to a centralized system is generally adopted for a blockchain, especially for a francis chain, and a large concurrent number of read-write test requests are initiated only for a certain single node in a blockchain network. However, due to the distributed nature of the blockchain, concurrent read/write test requests initiated for a single node are not centrally handled by one node, but rather, the stress caused by the test requests is distributed over the entire blockchain, which makes the TPS and/or QPS obtained by initiating a large concurrent number of read/write test requests only for a single node in the blockchain network inaccurate or even ineffective. Therefore, a method for measuring TPS and/or QPS of a blockchain system more accurately is needed to provide data support for current limit management in practical applications.

Furthermore, conventional stress testing of blockchains generally initiates testing directly on the bottom layer of the blockchain only, rather than testing the blockchain via the application layer (e.g., via the application programming interface server APIServer). However, in practical applications, the actual transaction needs to be implemented via the application layer. In view of this, a method capable of performing a stress test on the entire blockchain system (including the application layer) is needed.

Hereinafter, aspects of the present disclosure will be described in detail with reference to the accompanying drawings.

First, a method 10 for pressure testing of a blockchain system according to the present disclosure is described with reference to fig. 1.

as shown in fig. 1, the method starts at step S100.

At step S102, a blockchain is deployed on a single server. Here, deploying the blockchain on the single server means deploying an initial number of accounting node modules, consensus node modules and application programming interface server APIServer modules on the single server according to initial configuration parameters of the blockchain to form a complete blockchain system on the single server for testing.

Configuration parameters of the blockchain may include, for example, at least one or more of log level, block size, security transport layer protocol on state, consensus algorithm, P2P algorithm, accounting algorithm, and encryption algorithm, and different configuration parameters may affect the performance of the blockchain system in terms of TPS, CPU usage, memory usage, I/O operands, etc.

In particular, the log levels (e.g., low to high log levels may include ALL, TRACE, DEBUG, INFO, WARN, ERROR, far, OFF, etc.) may indicate how detailed events during a blockchain run are logged, e.g., a high log level may correspond to logging of fewer events, and thus less frequent input/output (I/O) operations, and a low log level may correspond to logging of more events, and thus more frequent I/O operations. The block size represents, for example, the number of transactions contained in one block. The TLS protocol is used to provide security such as confidentiality and data integrity for communications, and whether TLS is turned on or not affects the size of the traffic of messages in a blockchain network, differences in CPU usage caused by cryptographic operations, and the like. The "algorithm" referred to in the configuration parameters has a broad meaning, and may refer to a specific technique, protocol, and the like implemented by means of various algorithms, not only the algorithm itself in the narrow sense constituting the technique or protocol, but also different "algorithms" may have different complexities, and may affect the performance of the block chain to different degrees. For example, consensus algorithms may include Paxos, Raft, PBFT (practical byzantine fault tolerance), custom algorithms, and the like. The P2P algorithm may include Kademlia network, Gossip protocol or custom P2P algorithm, etc. The accounting algorithm may include a KV (Key-value) database or the like using levelDB, corehdb, or the like. The encryption algorithm may include a hash algorithm, an elliptic curve algorithm, a zero knowledge proof, SHA-256, and the like.

In accordance with the present disclosure, the initial configuration parameters of the blockchain may be randomly selected or predetermined. In fact, for some real blockchain system application scenarios as test targets, there may be certain requirements on configuration parameters. For example, when the application scenario of the real blockchain system has a high security requirement, it may be required that the TLS protocol must be started and a higher security encryption algorithm must be used. For another example, the application scenario of the real blockchain system may have a certain requirement on fault tolerance, for example, fault tolerance and rogue node may be required, in which case, the Raft algorithm that only fault tolerance of the fault node may not be suitable. In view of this, for those application scenarios with specific requirements on configuration parameters, the test blockchain system may be deployed on a single server with configuration parameters predetermined based on the application scenario. For other practical application scenarios without special requirements, the configuration parameters can be randomly selected.

According to the present disclosure, the initial number for the accounting node module, the consensus node module, and the APIServer module is 2, 1, and 1, respectively. Deploying the individual modules by this initial number may form the simplest blockchain system that can run multiple rounds of testing at S104. With this simplest configuration, a test system can be set up and a test started efficiently and quickly.

further, the modules may be deployed in a Docker container manner, which may enable reducing the impact of shared resources and/or host resource scheduling.

It is noted that deploying the blockchain system also includes storing contracts on various node modules on the blockchain, as is known in the art. In the blockchain field, contracts generally represent an automatically executable protocol that is reached between various nodes on the blockchain, and are automatically executed based on specific triggering events. In the test blockchain of the present invention, the simplest "contract" that can stress each node on the blockchain may be employed, for example, which may specify that data is written to the blockchain in the form of a "key-value" pair (i.e., consensus via a consensus node and synchronize the data to all nodes on the blockchain) based on a request initiated to some accounting node via an apicerver during testing. The specific testing operations based on this example contract will be further described below.

With continued reference to fig. 1, a chain of blocks deployed on a single server is contract-based multi-round tested via an APIServer module at S104, where one accounting node module is tested concurrently in each round of testing, and the concurrency number for each round of testing is adjusted until the concurrency number substantially saturates system resource usage by one of the accounting node module, the consensus node module, and the APIServer module. For example, system resource usage may include CPU usage or memory usage.

The test performed at S104 is explained in detail below with reference to fig. 2.

As shown in fig. 2, for each test, a contract-based test request may be sent by the pressure transmitter to some accounting node module via the APIServer module. The pressure transmitter may be a device dedicated to sending test requests for the blockchain system that is independent of the server that deployed the blockchain. For example, the pressure transmitter may be another server or computer separate from the server deploying the blockchain. In the case of the example contract described above, for each test, a request to write data in a blockchain in the form of a "key-value" pair may be sent by the pressure transmitter to some accounting node module via the APIServer module. As shown in fig. 2, the write request may be an HTTP POST request. It is noted that other protocol based requests may also be used as long as a data write request can be sent to the accounting node module. Due to the peer-to-peer relationship between the accounting nodes, a request can be made for a randomly selected accounting node module, and the tested accounting node may not be replaced during the test rounds. It should be noted that, because several test requests are performed on one accounting node module in a concurrent manner for each round of test, in order to avoid that the delay caused by the concurrent write operation lock affects the accuracy of the test, for multiple concurrent "key-value" pair write requests, the values of the keys between the respective write requests are different, for example, random key values may be adopted to prevent the concurrent write operation lock from being triggered by performing too many times of writes on the same key. There is no particular requirement for the value of the "key-value" median, and for example, a fixed value, a random value, or a value that increments in regular or irregular steps may be used.

During a multi-round test, as the number of concurrent requests (hereinafter also referred to as the number of concurrent requests or the number of concurrent test requests) is adjusted, it can be detected that when the number of concurrent requests increases to a certain degree, the system resource usage (e.g., CPU usage or memory usage) of one of the accounting node module, the consensus node module and the APIServer module tends to be stable (e.g., approximately stable at 90%), at which time the system resource usage of the module can be considered to be substantially saturated, and the module can be considered as a bottleneck module of the block chain system. Typically, the bottleneck module may be a billing node module or an apicerver module. When the system resource utilization rate of a certain module is detected to be basically saturated, the system resource utilization rate of the accounting node module and the system resource utilization rate of the consensus node module at the moment can be detected. For example, the system resource usage of the same type (e.g., CPU usage or memory usage) as the system resource usage that reached saturation for the accounting node module and the consensus node module may be detected at this time. In other words, for example, in the case that it is detected that the CPU usage of a certain module is substantially saturated, the CPU usage of the accounting node module and the CPU usage of the consensus node module at that time are detected, or for example, in the case that it is detected that the memory usage of a certain module is substantially saturated, the memory usage of the accounting node module and the memory usage of the consensus node module at that time are detected.

it is noted that the system resource utilization rate and the corresponding concurrency number of each module obtained during the multi-round test of S104 are only estimated values obtained under the test environment and are not exact values under the actual application environment, and the purpose of the method is mainly to provide theoretical guidance for building a typical test scenario (i.e. a test blockchain system built by using a plurality of servers) and building the actual application environment.

In accordance with the present disclosure, during multiple rounds of testing at S104, the multi-core utilization of the CPU by the various modules may also be detected. In this context, the multi-core utilization of a module to a CPU may represent whether the module can take full advantage of the CPU's multi-core. For example, for a module capable of fully utilizing the advantage of multiple cores of a CPU, when the pressure on the module rises, it may be detected that the module has a certain increase in the utilization rate of each core of the CPU, whereas for a module incapable of fully utilizing the advantage of multiple cores of the CPU, when the pressure on the module rises, it may be detected that only one core of the CPU has a certain increase in the utilization rate of the module, but the utilization rates of the other cores do not change significantly.

according to the present disclosure, as the number of concurrent requests to the accounting node modules increases, the pressure on each module increases accordingly. During the multiple testing rounds at S104, it may be detected whether the usage rate of each core of the CPU by each module increases with the increase of the number of concurrent requests, if for the module, the usage rate of only one core of the CPU increases with the increase of the number of concurrent requests, then the CPU multi-core utilization rate of the module may be considered to be low, that is, the module is difficult to utilize the CPU multi-core advantage, and in contrast, if the usage rate of each core of the CPU of the module increases with the increase of the number of concurrent requests, then the CPU multi-core utilization rate of the module may be considered to be high, that is, the module can fully utilize the CPU multi-core advantage.

With continued reference to fig. 1, at S106, a ratio between the number of accounting node modules and the number of consensus node modules for a typical stress test scenario is determined based on the system resource usage of each module when the system resource usage of the bottleneck module is substantially saturated, and an occupancy relationship of each module to the server is determined based on the multi-core utilization of each module to the CPU detected in the multi-round test.

Specifically, the ratio between the number of accounting node modules and the number of consensus node modules for a typical stress test scenario may be the same as the ratio between the system resource usage of the accounting node modules and the system resource usage of the consensus node modules when the system resource usage of the bottleneck modules is substantially saturated. The term "same ratio" herein can have a broader meaning. For example, since the actual ratio between system resource usage is likely not an integer ratio, the ratio between the number of accounting node modules and the number of consensus node modules may be rounded (with rounding or simply rounded up/down) as appropriate.

Determining the occupation relationship of each module to the server may include, for example, determining a module capable of fully utilizing the multi-core advantage of the CPU to be suitable for being deployed on one server separately, and determining two modules that are difficult to utilize the multi-core advantage of the CPU to be suitable for being deployed on the same server, based on the multi-core utilization ratio of each module to the CPU.

the method 10 ends at S108.

The method for pressure testing of a blockchain system according to the present disclosure has been described above with reference to fig. 1, 2. It is noted that the various steps in fig. 1 are merely exemplary, and that the method may include other steps in addition to those described above.

For example, after performing multiple rounds of concurrent tests based on the initial configuration parameters until the system resource utilization of the bottleneck module is substantially saturated and detecting the system resource utilization of each module at that time, multiple rounds of further tests may be additionally performed, and during the further tests, the configuration parameters of the blockchain deployed on a single server may be adjusted and further detected.

in particular, system resource usage of the modules corresponding to different configuration parameters and concurrency numbers that substantially saturate system resource usage of one of the accounting node module, consensus node module, and APIServer module may be detected. Based on the detection, configuration parameters corresponding to an optimal number of concurrencies may be determined as configuration parameters for a typical stress test scenario. The configuration parameter corresponding to the optimal number of concurrencies may be, for example, the configuration parameter corresponding to the maximum number of concurrencies. The configuration parameter corresponding to the optimal concurrency number may also be a configuration parameter corresponding to a lower system resource usage at the same maximum concurrency number.

In addition, the ratio of the system resource utilization rate between the accounting node module and the consensus node module when the system resource utilization rate of one of the accounting node module, the consensus node module and the APIServer module under the configuration parameters corresponding to the optimal concurrency number is substantially saturated can be determined as the ratio of the number of the accounting node modules and the number of the consensus node modules for the typical stress test scenario based on the detection. The bottleneck modules under different configuration parameters may be the same or different. Thus, the bottleneck module detected here during further testing may be the same or different from the bottleneck module detected under testing of the blockchain deployed with the initial configuration parameters. It should be noted that the purpose of detecting the bottleneck module is mainly to determine the proportional relationship between the number of the accounting node modules and the number of the consensus node modules when the system reaches the performance bottleneck, and therefore it is not important which module has the system resource utilization rate saturated, as long as the ratio of the system resource utilization rates between the accounting node modules and the consensus node modules at this time is detected to determine the quantity ratio.

Further, if there are multiple configuration parameters corresponding to the optimal concurrency number, the ratio of the maximum probability between the number of accounting node modules and the number of consensus node modules may be determined according to multiple ratios of system resource usage between accounting node modules and consensus node modules corresponding to different configuration parameters. For example, there are four configuration parameters corresponding to the optimal concurrency number, and four system resource usage ratios between the accounting node module and the identifying node module corresponding to the various configuration parameters are detected, respectively: {8/1, 8/1, 9/1, 7/1}, where the maximum probability ratio between the number of accounting node modules and the number of consensus node modules for a typical stress test scenario may be determined to be 8/1.

For another example, during a plurality of further testing rounds additionally performed after performing a plurality of concurrent tests based on the initial configuration parameters until the system resource utilization of the bottleneck module is substantially saturated and detecting the system resource utilization of each module at that time, the number of the accounting node modules may be appropriately adjusted, a system resource utilization ratio between the accounting node module and the consensus node module when the bottleneck modules corresponding to different numbers of the accounting node modules are saturated may be detected, and a ratio of a maximum probability between the number of the accounting node modules and the number of the consensus node modules may be determined according to the detected plurality of system resource utilization ratios. Adjusting the number of accounting node modules may make the ratio between the number of accounting node modules finally determined and the number of consensus node modules more accurate than testing with only one consensus node module and two accounting node modules.

Further, it is also possible to adjust both the configuration parameters and the number of accounting node modules during the above further testing.

The specific operations for testing a blockchain system deployed on a single server have been described above. As shown in fig. 3, according to the present disclosure, stress testing of the blockchain system may further include deploying the blockchain on a plurality of servers according to a test result on a single server to construct a typical stress test scenario after testing the blockchain system deployed on the single server, and testing the blockchain system deployed on the plurality of servers.

The modules may be deployed over multiple servers based on the ratio between the number of accounting node modules and the number of consensus node modules for a typical stress test scenario as determined by blockchain testing on a single server and the occupancy of the modules to the server. As explained above, the number of the accounting node modules and the common node modules may be configured in a ratio between the system resource usage rate of the accounting node module and the system resource usage rate of the common node module when the system resource usage rate of the bottleneck module is substantially saturated, and a module capable of making full use of the multi-core advantage of the CPU may be separately deployed on one server and two modules difficult to make use of the multi-core advantage of the CPU may be deployed on the same server based on the multi-core utilization rate of each module to the CPU.

In particular, to better comply with the practical application, each node module (e.g. consensus node module and accounting node module) may be deployed on separate servers, i.e. typically no two node modules (e.g. two accounting node modules or one accounting node module and one consensus node module) are deployed on the same server, and preferably no consensus node module is deployed on the same server as the APIServer module. For example, when CPU multi-core utilization of both the APIServer module and the billing node module is determined to be low through blockchain testing on a single server, the APIServer modules may be configured in the same number as the billing node modules, and one APIServer module and one billing node module may be deployed on each server. For another example, when it is determined through a blockchain test on a single server that the CPU multi-core utilization of the APIServer module is high, only one separate server may be utilized to deploy one APIServer module as an application layer interface module of a blockchain disposed on multiple servers, and each accounting node module may be deployed on a separate server, regardless of whether the accounting node module is capable of fully utilizing the CPU multi-core advantage.

after the blockchain system is deployed on a plurality of servers, multiple rounds of concurrent tests can be performed on the blockchain deployed on the plurality of servers through the APIServer module based on contracts, and the transaction rate per second of the block chain and/or the system resource utilization rate of each server under each round of concurrent tests can be detected, wherein a plurality of accounting node modules are concurrently tested in each round of tests and the same accounting node module is concurrently tested, and the concurrent number of each round of concurrent tests is different. Testing of a blockchain system deployed on multiple servers may be conducted with the same contracts used in testing for blockchain systems deployed on a single server. For example, similar to the tests on a single server, for each test, a request to write data in a "key-value" pair to a blockchain may be sent by the pressure transmitter to some accounting node module via the APIServer. The pressure transmitter may be a separate server or computer independent of the plurality of servers deploying the blockchain system.

The main purpose of the testing of the blockchain system on multiple servers is to mine the maximum TPS of the blockchain system. According to the disclosure, the TPS of the blockchain system or the TPS at a certain system resource usage rate is tested by adjusting the concurrency number. Here, "different number of concurrencies" has two implications, on the one hand the number of accounting node modules for each round of concurrent testing is different, on the other hand the number of concurrent test requests for a single accounting node module is different. It will be appreciated that for two successive runs, the number of accounting node modules targeted for the run may be maintained and the number of concurrent test requests for a single accounting node module may be adjusted, or the number of concurrent test requests for a single accounting node module may be maintained and the number of accounting node modules targeted for the run may be adjusted, or both concurrent numbers may be changed, as long as TPS of different block chain systems under concurrent numbers can be adequately tested.

Further, testing of the blockchain system on multiple servers may also be done for QPS, in which case the contract may be modified so that on a per test basis, a read of data stored on the blockchain is requested. For example, a contract may be such that for each test, a request is made to read the corresponding "value" identified by the "key".

The method for pressure testing of a blockchain system according to the present disclosure has been described above with reference to fig. 1-3.

According to the present disclosure, deploying the blockchain system on a single server may make system environments (e.g., CPU, memory, network bandwidth, etc.) for each module consistent, and thus may conveniently analyze and compare consumption degrees of each module for each system resource without a difference in resource consumption degrees due to inconsistency of hardware environments, and may further quickly and effectively determine a bottleneck module in the blockchain system, and accordingly determine a ratio between the number of accounting node modules and the number of consensus node modules used in a typical pressure test scenario or an actual application scenario, an occupation relationship of each module to the server, configuration parameters of the blockchain, and the like.

According to the method and the device, the maximum TPS of the system can be effectively mined by performing multiple rounds of tests with different concurrency numbers on the block chains deployed on a plurality of servers (namely the block chains in a typical pressure test scene), so that data support is provided for current limiting management and control. For example, when it is found through testing that the TPS of the blockchain system is not large enough under a certain system resource utilization rate, it may be considered that an application with frequent transaction writes is not configured on the blockchain system when the blockchain system is actually applied, or it may be considered that further limitation is performed on the transaction writes on the blockchain system.

According to the present disclosure, instead of testing the blockchain underlying architecture directly, the test is performed through the APIServer module as an interface between the blockchain underlying architecture and the application layer, which makes the test closer to the actual application situation to obtain more accurate data. In addition, since the APIServer module may also become a bottleneck module in the blockchain system, the deployment mode of the blockchain system (for example, the proportional relationship between the number of the node modules and the occupation situation of each module on the server) is determined under the condition that the occupancy rate of the APIServer module on the system resources is considered, and a deployment scheme with more practical guiding significance can be obtained.

The general aspects of the present disclosure and its advantages have been described above. Next, an example of a test performed using the method of the present disclosure will be described.

first, a block chain architecture used in a test example using the method of the present disclosure is briefly described with reference to fig. 4.

In this test example, a hyper ledger (hyper hedger) is adopted as the block chain architecture. As shown in fig. 4, the underlying architecture of the super ledger is mainly composed of three parts, namely membership service, blockchain service and chain code service. The function of the membership service, which is not the focus of this test example and is not described in detail herein, is to manage the identity, privacy and confidentiality and the like of the network. The function of the chained code service is mainly to provide an environment for the nodes to be able to execute chained codes, for example, the chained code service may use a Docker to run the chained codes. The term "chained code" as used in the super book may be understood as a piece of decentralized program running on a node of the blockchain, which may be equivalent in meaning to the "contract" described above. The main function of the blockchain service is to generate and manage a distributed ledger of blockchains. The blockchain service can be mainly realized by two node modules, namely a consensus node module and an accounting node module. The consensus node module can realize a consensus algorithm and a consensus manager, and the consensus manager can define interfaces between the consensus algorithm and other components of the super account book; a point-to-point (P2P) protocol may be defined on the accounting node module and may implement ledger storage functions and the like.

As shown in fig. 4, the super ledger architecture further includes an application layer, which may configure, invoke and/or manage the underlying service modules of the super ledger architecture by means of an application programming interface server (APIServer), wherein the APIServer may be developed by means of a Software Development Kit (SDK). For example, membership, blockchains, transactions, chain codes, etc. related content may be conveniently accessed via the application layer.

Next, a specific operation procedure of a test example using the method of the present disclosure under the super ledger architecture will be described.

First, 2 accounting node modules (peers), 1 consensus node module (orderer), and 1 application programming interface server module (APIServer) are deployed on a single server according to the initial configuration parameters of the blockchain. The initial configuration parameters are set as shown in table 1, wherein for the consensus algorithm, zookeeper + kafka may be adopted to implement consensus in the super book (zookeeper is a distributed application coordination service, which may provide a Paxos consensus algorithm, and kafka is a distributed message queue for business logic), and wherein, in addition to the P2P algorithm being non-configurable, other configuration parameters may be configured in this test example to choose other available parameters different from the parameters listed in table 1.

Consensus algorithm	Zookeeper+kafka
		Encryption algorithm	SHA-256, elliptic Curve digital signature
Accounting algorithm	levelDB database
		P2P algorithm	gossip protocol and gRPC channel
APIServer implementation	Nodejs
		Log level	INFO
Block size	99M
		TLS on State	Close off

TABLE 1

Subsequently, a plurality of concurrent tests may be performed on one accounting node module using the method shown in fig. 2, wherein a request to write "key-value" data to the blockchain is concurrently performed on one accounting node module in each test. The configuration of the server and the pressure transmitter used in this test example is shown in table 2.

TABLE 2

As the number of concurrencies increases, it is detected that the CPU utilization of the APIServer module first reaches saturation. At this time, the ratio of the CPU utilization rates of the accounting node module and the consensus node module is detected to be 8: 1. Thus, the ratio between the number of accounting node modules and the number of consensus node modules for a typical stress test scenario was determined to be 8: 1. In addition, as the concurrency number increases, it is detected that neither the APIServer module nor the accounting node module can utilize the advantage of multiple cores of the CPU, and therefore, it is determined that one APIServer module and one accounting node module are configured on the same server, and a consensus node module is configured on a separate server in a typical stress test scenario.

Next, individual modules are deployed on multiple servers based on the results of the tests on a single server. FIG. 5 shows a schematic diagram of a typical test system deployed over multiple servers under this test example. As shown in fig. 5, eight pairs of APIServer modules and accounting node modules are deployed on eight servers, respectively, one consensus node module is deployed on a separate server, and the pressure transmitter is a separate server. Similar to the test on a single server, the configuration of the pressure transmitter used and the individual servers is shown in table 2.

In this test example, multiple rounds of concurrent testing of a blockchain deployed on multiple servers are performed on a pressure transmitter using a test script via an APIServer module, wherein requests to write "key-value" data to the blockchain are made concurrently to multiple accounting node modules in each round of testing, and several write requests are made concurrently to the same accounting node module, and wherein the number of concurrencies for each round of concurrent testing is different. Additionally, in this test case, a read request is also made concurrently to the accounting node module, for example requesting to read the corresponding "value" identified by the "key".

In this test example, it is detected that when a contract invocation request with a duration of 300 seconds is initiated for 15 threads from each APIServer module, the TPS of the blockchain system reaches an optimal value 280 (transaction/second), at this time, the peak value of the CPU usage rate of each APIServer module reaches over 90%, the CPU usage rate of the consensus node module reaches about 80%, and in addition, it is detected that the QPS at this time is 343 (query/second).

Fig. 6 illustrates an exemplary configuration of a computer device 2000, in which embodiments according to the present disclosure may be implemented. The computer device 2000 is an example of a hardware device to which the control apparatus for the pressure test of the blockchain system of the present disclosure can be applied. The computer device 2000 may be any machine configured to perform processing and/or computing. The computer device 2000 may be, but is not limited to, a workstation, a server, a desktop computer, a laptop computer, a tablet computer, a Personal Data Assistant (PDA), a smart phone, an in-vehicle computer, or a combination thereof.

As shown in fig. 6, computer device 2000 may include one or more elements connected to or in communication with bus 2002, possibly via one or more interfaces. For example, the computer device 2000 may include a bus 2002, one or more processors 2004, one or more input devices 2006, and one or more output devices 2008. Bus 2002 may include, but is not limited to, an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an enhanced ISA (eisa) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus, among others. The one or more processing devices 2004 can be any kind of processor and can include, but are not limited to, one or more general-purpose processors or special-purpose processors (such as special-purpose processing chips). Input device 2006 may be any type of input device capable of inputting information to a computer device and may include, but is not limited to, a mouse, a keyboard, a touch screen, a microphone, and/or a remote controller. Output device 2008 may be any type of device capable of presenting information and may include, but is not limited to, a display, speakers, a video/audio output terminal, a vibrator, and/or a printer. The computer device 2000 may also include or be connected to a non-transitory storage device 2010, which non-transitory storage device 2010 may be any non-transitory and may implement a data storage device, and may include, but is not limited to, a disk drive, an optical storage device, a solid state memory, a floppy disk, a flexible disk, a hard disk, a magnetic tape, or any other magnetic medium, a compact disk, or any other optical medium, a ROM (read only memory), a RAM (random access memory), a cache memory, and/or any other memory chip or module, and/or any other medium from which a computer may read data, instructions, and/or code. The non-transitory storage device 2010 may be removably connected with any interface. The non-transitory storage device 2010 may have stored thereon data/instructions/code for implementing the aforementioned methods and/or steps of conducting transactions via a two-tier federation chain. The computer device 2000 may also include a communication device 2012, which communication device 2012 may be capable of enabling communication with external devices and/or networksAnd may include, but is not limited to, a modem, a network card, an infrared communication device, a wireless communication device, and/or a chipset (such as bluetooth)^TMDevices, 1302.11 devices, WiFi devices, WiMax devices, cellular communications facilities, etc.).

The computer device 2000 may also include a working memory 2014. The working memory 2014 may be any type of working memory capable of storing instructions and/or data useful to the processor 2004 and may include, but is not limited to, Random Access Memory (RAM) and Read Only Memory (ROM).

the software elements located on the above-described working memory may include, but are not limited to, an operating system 2016, one or more application programs 2018, drivers, and/or other data and code. One or more of the applications 2018 described above may include instructions for controlling the execution of a method for stress testing of a blockchain system as described above. Execution of the stress test for the blockchain system according to the present disclosure may be controlled by a processor reading and executing one or more applications 2018. More specifically, the configuration of the respective modules on the servers may be controlled by the application 2018, which may be accomplished by controlling the invocation of the corresponding module code on the corresponding server, for example. Further, the execution of test scripts, such as contracts, may also be controlled by application 2018. Further, the application 2018 may also be used to control and detect the corresponding system resource utilization rate and the CPU multi-core utilization rate on the corresponding server, and perform, for example, calculation of the system resource utilization rate ratio. Executable code or source code of the instructions of the software elements may be stored in a non-transitory computer-readable storage medium (such as storage device 2010 as described above) and may be read into working memory 2014 by compilation and/or installation. Executable or source code for the instructions of the software elements may also be downloaded from a remote location. In addition, a parameter profile may be stored in the working memory to specify storage locations for various operating parameters and/or data, and the like.

It will be appreciated that variations may be made in accordance with specific requirements. For example, customized hardware might be used and/or particular elements might be implemented in hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. In addition, connections to other computer devices (such as network input/output devices) may be employed. For example, some or all of the methods and apparatus of the present disclosure may be implemented in accordance with the present disclosure using assembly language programming hardware (e.g., programmable logic circuits including Field Programmable Gate Arrays (FPGAs) and/or Programmable Logic Arrays (PLAs)) or software programming languages (e.g., Golang, C + +, java, etc.).

It should be further understood that the elements of the computer device 2000 may be distributed throughout a network. For example, some processes may be performed using one processor while other processes are performed using other remote processors. Other elements of the computer system 2000 may be similarly distributed. Thus, the computer device 2000 may be understood as a distributed computing system that performs processing at multiple locations.

The methods and apparatus of the present disclosure may be implemented in a number of ways. For example, the methods and apparatus of the present disclosure may be implemented by software, hardware, firmware, or any combination thereof. The order of the method steps described above is merely illustrative, and the method steps of the present disclosure are not limited to the order specifically described above unless explicitly stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as a program recorded in a recording medium, which includes machine-readable instructions for implementing a method according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for implementing the method according to the present disclosure.

While some specific embodiments of the present disclosure have been shown in detail by way of example, it should be understood by those skilled in the art that the foregoing examples are intended to be illustrative only and are not limiting upon the scope of the present disclosure. It will be appreciated by those skilled in the art that the above-described embodiments may be modified without departing from the scope and spirit of the disclosure. The scope of the present disclosure is defined by the appended claims.

Claims

1. A method for pressure testing of a blockchain system, comprising:

deploying accounting node modules, consensus node modules and application programming interface server APIServer modules in initial quantity on a single server according to initial configuration parameters of a block chain;

Performing multiple rounds of testing on a blockchain deployed on a single server based on contracts via an APIServer module, wherein one accounting node module is tested concurrently in each round of testing, and adjusting a concurrency number for each round of testing until the concurrency number substantially saturates system resource utilization of one of the accounting node module, the consensus node module, and the APIServer module; and

And determining the proportion between the number of accounting node modules and the number of consensus node modules for a typical stress test scene based on the system resource utilization rate of each module when the system resource utilization rate of the module is basically saturated, and determining the occupation relationship of each module to a server based on the multi-core utilization rate of each module to the CPU detected in the multi-round test.

2. The method of claim 1, wherein,

The system resource utilization rate comprises a CPU utilization rate or a memory utilization rate.

3. The method of claim 2, wherein

The proportion between the number of the accounting node modules and the number of the consensus node modules for a typical stress test scene is the same as the proportion between the system resource utilization rate of the accounting node module and the system resource utilization rate of the consensus node module when the system resource utilization rate of the module is basically saturated; and

Based on the multi-core utilization rate of each module to the CPU, a module capable of fully utilizing the multi-core advantage of the CPU is determined to be suitable for being separately deployed on one server, and two modules which are difficult to utilize the multi-core advantage of the CPU are determined to be suitable for being deployed on the same server.

4. The method of any one of claims 1-3, further comprising:

Deploying the modules on a plurality of servers based on the determined ratio of the number of accounting node modules and the number of consensus node modules for the typical stress test scenario and the occupation relationship of the modules to the servers;

performing, via the APIServer module, multiple rounds of concurrent testing on a blockchain deployed on a plurality of servers based on the contracts, wherein multiple accounting node modules are tested concurrently in each round of testing and the same accounting node module is tested concurrently, and wherein the number of concurrencies for each round of concurrent testing is different; and

And detecting the TPS and/or the system resource utilization rate of each server under each round of concurrent test.

5. The method of any one of claims 1-3, wherein

The configuration parameters of the blockchain include at least one or more of log level, block size, secure transport layer protocol on state, consensus algorithm, P2P algorithm, accounting algorithm, and encryption algorithm, and

the initial configuration parameters of the blockchain are randomly selected or predetermined.

6. The method of any one of claims 1-3, wherein

The initial number for the accounting node module, consensus node module and APIServer module is 2, 1 and 1, respectively.

7. The method of any one of claims 1-3, wherein

The method also includes adjusting configuration parameters of the blockchain deployed on a single server;

Detecting the system resource utilization rate of each module corresponding to different configuration parameters and the concurrency number of the system resource utilization rate of one module of the accounting node module, the consensus node module and the APIServer module which is basically saturated; and

And determining the configuration parameters corresponding to the optimal concurrency number as the configuration parameters for the typical stress test scene, and determining the proportion of the system resource utilization rate between the accounting node module and the consensus node module when the system resource utilization rate of one of the accounting node module, the consensus node module and the APIServer module under the configuration parameters corresponding to the optimal concurrency number is basically saturated as the proportion of the number of the accounting node modules and the number of the consensus node modules for the typical stress test scene.

8. The method of any one of claims 1-3, wherein

The contract causes key-value pairs to be written on the blockchain, with different keys being employed between concurrent tests in each round of testing.

9. A computer-readable medium having stored thereon computer-executable instructions that, when executed by a processor, cause the processor to perform the method of any one of claims 1-8.

10. A control device for pressure testing of a blockchain system, the control device comprising a memory storing computer executable instructions and a processor, which when executed by the processor, cause the device to perform the method of any one of claims 1-8.