search

dongmingh / v1performance

13 stars 14 forks source link

readme

Performance Traffic Engine - PTE

The Performance Traffic Engine (PTE) uses SDKs to interact with Hyperledger Fabric networks by sending requests to and receiving responses from one or more networks. Currently, PTE only uses Hyperledger Fabric Client (HFC) Node SDK and will include other SDKs in the future.

PTE is designed to meet two-fold requirements:

  1. to handle the complexity of the Hyperledger Fabric network, e.g., locations and number of network, number of channels, organizations, peers, orderers etc.
  2. to support various test cases, e.g., various chaincodes, transaction number, duration, mode, type, and payload size etc,

In order to meet the two-fold requirements above, flexibility and modularity are the primary design concepts of PTE regarding implementation and usage. Moreover, PTE provides users many options for their test cases, see below for available options. The design of PTE is demonstrated in the diagram below:

In brief, PTE has the following features:

Table Of Contents:

Code Base for v1.0.0

Future items

Prerequisites

To build and test the following prerequisites must be installed first:

If planning to run your Fabric network locally, you'll need docker and a bit more. See Hyperledger Fabric - Getting Started for details. `

Setup

  1. Download fabric-test sources:

    • go get -d github.com/hyperledger/fabric-test

  2. Download or update fabric, fabric-ca, and fabric-sdk-node sources, see Hyperledger fabric-test for details:

    • cd $GOPATH/src/github.com/hyperledger/fabric-test
    • if first time:
      • git submodule update --init --recursive
      • git submodule foreach git pull origin master
    • else:
      • git submodule foreach git pull origin master

  3. Obtain appropriate docker images:

    Optionally, you may choose to skip this step of obtaining fabric and fabric-ca images if plan to run PTE against a remote Fabric network. See Creating a local Fabric network for additional information on this.

    • fabric
      • download from dockerhub:
        • cd $GOPATH/src/github.com/hyperledger/fabric-test/fabric/scripts
        • If testing v1.0.0: ./bootstrap-1.0.0.sh
      • build images yourself (v1.0.0 shown here):
        • cd $GOPATH/src/github.com/hyperledger/fabric-test/fabric/
        • git checkout v1.0.0
        • make docker
    • fabric-ca
      • cd $GOPATH/src/github.com/hyperledger/fabric-test/fabric-ca
      • git checkout v1.0.0
      • make docker
    • fabric-sdk-node
      • cd $GOPATH/src/github.com/hyperledger/fabric-test/fabric-sdk-node
      • If testing v1.0.0: git checkout v1.0.0
      • npm install
        • you should be able to safely ignore any warnings
      • gulp ca

  4. Install PTE:

    • cd $GOPATH/src/github.com/hyperledger/fabric-test/tools
    • cp -r PTE $GOPATH/src/github.com/hyperledger/fabric-test/fabric-sdk-node/test

  5. Create Service Credentials file(s) for your Fabric network:

    • See the examples in SCFiles and change the address to your own Fabric addresses and credentials. Add a block for each organization and peer, ensuring correctness.

  6. Specify run scenarios:

    • Create your own version of PTEMgr.txt (if use pte_mgr.sh), runCases.txt and User Input json files, according to the test requirements. Use the desired chaincode name, channel name, organizations, etc. Using the information in your own network profiles, remember to "create" all channels, "join" channel, and "install" and "instantiate" chaincode for each org, to ensure all peers are set up correctly. Additional information can be found below.

Running PTE

Before attempting to run PTE ensure your network is running! If you do not have access to a Fabric network, please see the section on Creating a local Fabric network.

Usage

There are two ways to execute PTE: pte_mgr.sh and pte_driver.sh. pte_mgr.sh can be used to manage multiple PTEs while pte_driver.sh can only manage one PTE.

Transaction Execution

A single test case is described by a user input file. User input files define all the parameters for executing a test; including transaction type, number of processes, number of transactions, duration, etc. All processes in one test case will concurrently execute the specified transaction. Different transactions may be used in different test cases and then combined into a single run cases file, making it possible to create more complicated scenarios. For example, in a single run of PTE, a user could send a specific number of invokes to all peers and then query each peer separately.

Transaction Type

Sample Use Cases

Additional Use Cases

Although PTE's primary use case is to drive transactions into a Fabric network, it can be used for creating and joining channels, and chaincode installation and instantiation. This gives the ability for more complete end-to-end scenarios.

Chaincodes

The following chaincodes are tested and supported:

Output

Reference

User Input file

{
    "channelID": "_ch1",
    "chaincodeID": "sample_cc",
    "chaincodeVer": "v0",
    "logLevel": "ERROR",
    "invokeCheck": "TRUE",
    "transMode": "Constant",
    "transType": "Invoke",
    "invokeType": "Move",
    "targetPeers": "OrgAnchor",
    "peerFailover": "TRUE",
    "ordererFailover": "TRUE",
    "nProcPerOrg": "4",
    "nRequest": "0",
    "runDur": "600",
    "TLS": "enabled",
    "queryBlockOpt": {
        "org":  "org1",
        "peer":  "peer1",
        "startBlock":  "6590",
        "endBlock":  "6800"
    },
    "channelOpt": {
        "name": "testchannel1",
        "channelTX": "/root/gopath/src/github.com/hyperledger/fabric-test/fabric/common/tools/cryptogen/crypto-config/ordererOrganizations/testorgschannel1.tx",
        "action":  "create",
        "orgName": [
            "org1"
        ]
    },
    "burstOpt": {
        "burstFreq0":  "500",
        "burstDur0":  "3000",
        "burstFreq1": "2000",
        "burstDur1": "10000"
    },
    "mixOpt": {
        "mixFreq": "2000"
    },
    "constantOpt": {
        "recHIST": "HIST",
        "constFreq": "1000",
        "devFreq": "300"
    },
    "listOpt": {
        "org1": ["peer1"],
        "org2": ["peer1"]
    },
    "eventOpt": {
        "type": "Channel",
        "listener": "Transaction",
        "timeout": "240000"
    },
    "failoverOpt": {
        "method": "RoundRobin",
        "list": "targetPeers"
    },
    "ccType": "general",
    "ccOpt": {
        "keyIdx": [1],
        "keyPayLoad": [2],
        "keyStart": "5000",
        "payLoadType": "Random",
        "payLoadMin": "1024",
        "payLoadMax": "2048"
    },
    "deploy": {
        "chaincodePath": "github.com/hyperledger/fabric-test/fabric-sdk-node/test/fixtures/src/github.com/sample_cc",
        "fcn": "init",
        "language": "golang"
        "args": []
    },
    "invoke": {
        "query": {
            "fcn": "invoke",
            "args": ["get", "a"]
        },
        "move": {
            "fcn": "invoke",
            "args": ["put", "a", "string-msg"]
        }
    },
    "SCFile": [
        {"ServiceCredentials":"SCFiles/config-chan1-TLS.json"}
    ]
}

where:

Service Credentials file

The service credentials contain the information of the network and are stored in the SCFiles directory. The following is a sample of the service credentials json file:

{
    "test-network": {
        "orderer": {
                "name": "OrdererMSP",
                "mspid": "OrdererMSP",
                "mspPath": "./crypto-config",
                "adminPath": "./crypto-config/ordererOrganizations/example.com/users/Admin@example.com/msp",
                "comName": "example.com",
                "url": "grpcs://localhost:5005",
                "server-hostname": "orderer0.example.com",
                "tls_cacerts": "./crypto-config/ordererOrganizations/example.com/orderers/orderer0.example.com/msp/cacerts/ca.example.com-cert.pem"
        },
        "org1": {
                "name": "Org1MSP",
                "mspid": "Org1MSP",
                "mspPath": "./crypto-config",
                "adminPath": "./crypto-config/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp",
                "comName": "example.com",
                "ca": {
                     "url":"https://localhost:7054",
                     "name": "ca-org1"
                },
                "username": "admin",
                "secret": "adminpw",
                "peer1": {
                        "requests": "grpc://localhost:7061",
                        "events": "grpc://localhost:7051",
                        "server-hostname": "peer0.org1.example.com",
                        "tls_cacerts": "../fixtures/tls/peers/peer0/ca-cert.pem"
                },
                "peer2": {
                        "requests": "grpc://localhost:7062",
                        "events": "grpc://localhost:7052",
                        "server-hostname": "peer1.org1.example.com",
                        "tls_cacerts": "../fixtures/tls/peers/peer0/ca-cert.pem"
                }
        },
        "org2": {
                "name": "Org2MSP",
                "mspid": "Org2MSP",
                "mspPath": "./crypto-config",
                "adminPath": "./crypto-config/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp",
                "comName": "example.com",
                "ca": {
                     "url":"https://localhost:8054",
                     "name": "ca-org2"
                },
                "username": "admin",
                "secret": "adminpw",
                "peer1": {
                        "requests": "grpcs://localhost:7063",
                        "events": "grpcs://localhost:7053",
                        "server-hostname": "peer0.org2.example.com",
                        "tls_cacerts": "./crypto-config/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/msp/cacerts/ca.org2.example.com-cert.pem"
                },
                "peer2": {
                        "requests": "grpcs://localhost:7064",
                        "events": "grpcs://localhost:7054",
                        "server-hostname": "peer1.org2.example.com",
                        "tls_cacerts": "./crypto-config/peerOrganizations/org2.example.com/peers/peer1.org2.example.com/msp/cacerts/ca.org2.example.com-cert.pem"
                }
        }
    }
}

Creating a local Fabric network

CI Test

A set of predefined tests are designed for CI daily or weekly execution and are available in the directory, CITest, under PTE.

Remote PTE

This feature allows user to execute PTE (PTE manager and/or driver) to send transactions from remote hosts to Blockchain networks, see diagram below.

In order to execute PTE remotely, the PTE controller host will need to have access to the remote PTE hosts. In the setup below, ssh auto login without password is illustrated. However, users should choose any preferred remote access method between PTE controller host and remote PTE hosts for their environment.

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.