本教學將帶您完成在預先存在的Fabric網路上使用Caliper對智慧合約進行效能測試。
要完成本教學,您需要安裝NodeJS。為此,我們建議使用nvm。
本教學基於官方Hyperledger Fabric檔案中提供的資源。假設一個由兩個組織和一個單獨排序者組成的網路,具有asset-transfer-basic
的javascript智慧合約,假定已經建立並準備好進行效能測試。
下面的命令列表是一個最簡單的快速步驟指南,用於啟動和執行所需的Fabric網路。我們在顯式級別使用可用的Hyperledger Fabric資源。要了解並排除建立測試網路期間發生的情況,請參閱上面連結的Fabric檔案!
# 克隆Hyperledger Fabric samples repo的固定版本
git clone https://github.com/hyperledger/fabric-samples.git
cd fabric-samples
git checkout 22393b629bcac7f7807cc6998aa44e06ecc77426
# 安裝Fabric工具並將其新增到PATH
curl -sSL https://bit.ly/2ysbOFE | bash -s -- 2.2.0 1.4.8 -s
export PATH=$PATH:$(pwd)/bin
# 建立並初始化網路
cd test-network
./network.sh up createChannel
./network.sh deployCC -ccn basic -ccl javascript
在fabric-samples目錄的同一級別建立一個名為caliper-workspace的資料夾,然後在caliper-workspace資料夾中,分別建立三個名為networks、benchmarks和workload的資料夾
Caliper的安裝和使用將基於當地的npm安裝。在caliper-workspace目錄中,使用以下終端命令安裝caliper CLI:
npm install --only=prod @hyperledger/caliper-cli@0.4.0
使用以下終端命令繫結SDK:
npx caliper bind --caliper-bind-sut fabric:2.1
有關Caliper安裝和捆綁的更多資訊,請參見相關檔案頁。
Caliper需要兩個組態檔:
現在我們將用Caliper所需的資源填充這些資料夾。
網路組態檔是Caliper工作人員建立到現有Fabric網路的連線所需的檔案,以便他們可以提交交易。它類似於Fabric公共連線組態檔,並新增了其他必需欄位。檔案可以是YAML或JSON格式,本教學顯示JSON格式。
在「networks」資料夾下建立一個名為networkConfig.json包括以下內容:
{
"version" : "1.0",
"name": "Caliper test",
"caliper" : {
"blockchain": "fabric"
},
"clients" : {
},
"channels" : {
},
"organizations" : {
},
"peers" : {
}
}
版本:正在使用的組態檔的版本。只接受「1.0」。
名稱:設定的名稱,在本例中為「Caliper測試」。
Caliper:指示對目標的SUT進行Caliper,可能包含本教學中不需要的其他開始/結束命令。在本教學中,我們以Fabric網路為目標。
使用者端:列出要在效能測試中使用的標識
通道:描述可用的Hyperledger Fabric通道、它們的狀態以及在這些通道上部署的智慧合約
組織:要在基準測試中使用的超級賬本Fabric組織
節點:要在基準測試中使用的Hyperledger Fabric節點
在測試網路教學之後,將生成一個公共連線組態檔(CCP);我們將使用此檔案幫助填充Caliper網路組態檔的特定於Hyperledger Fabric的元素。模板將為所建立的Hyperledger Fabric網路提供一些唯一的證書,因此您將注意到後續階段中顯示的內容的差異;您必須使用為與您希望目標的測試網路進行互動而建立的證書。
在本例中,我們將使用Org1進行連線。要查詢生成的JSON或yamlccp檔案,請檢視fabric-samples -> test-network -> organizations -> peerOrganizations -> org1.example.com。 我們假設使用json CCP connection-org1.json。
組織和同行
使用CCP的內容進行填充:
將CCP的organizations
和peers
元素複製到Caliper網路組態檔中。
在organizations.Org1
物件,刪除certificateAuthorities
列表。這樣做有兩個原因:
i) 我們不會使用證書頒發機構註冊或註冊
ii)向CCP提交的變更與組態檔中的驗證Caliper不相容。
Caliper網路組態檔現在應該類似於:
{
"version" : "1.0",
"name": "Caliper test",
"caliper" : {
"blockchain": "fabric"
},
"clients" : {
},
"channels" : {
},
"organizations": {
"Org1": {
"mspid": "Org1MSP",
"peers": [
"peer0.org1.example.com"
]
}
},
"peers": {
"peer0.org1.example.com": {
"url": "grpcs://localhost:7051",
"tlsCACerts": {
"pem": "-----BEGIN CERTIFICATE-----<UNIQUE CONTENT>-----END CERTIFICATE-----\n"
},
"grpcOptions": {
"ssl-target-name-override": "peer0.org1.example.com",
"hostnameOverride": "peer0.org1.example.com"
}
}
}
}
使用者端
指定執行基準測試時Caliper要使用的標識。身份必須有效,這意味著它們必須為Fabric網路所知,並且具有相應的加密材料以供使用。標識在clients
節中列出。這裡我們使用單一身份Admin@org1.example.com
,我們在其中巢狀來自CCP的client物件,以指示標識所屬的組織,並提供基本的連線超時資訊。
"clients": {
"Admin@org1.example.com": {
"client": {
"organization": "Org1",
"connection": {
"timeout": {
"peer": {
"endorser": "300"
}
}
}
}
}
}
在client物件下,新增一個名為credentialStore
的屬性,在該屬性下新增一個名為path
的屬性,該屬性具有一個字串變數,該變數指向工作區中名為/tmp/org1
的臨時檔案。另外,在credentialStore
屬性下新增一個名為cryptoStore
的屬性,並在該屬性下新增另一個指向上面相同臨時檔案/tmp/org1
的路徑屬性。
以下是應該新增到client
的內容:
"credentialStore": {
"path": "/tmp/org1",
"cryptoStore": {
"path": "/tmp/org1"
}
}
在client
物件下新增一個名為clientPrivateKey
的屬性,在此屬性下新增一個名為path
的屬性,該屬性具有一個字串變數,該變數指向標識的私鑰。請注意,提供的路徑是相對於工作區的。在本例中,私鑰位於fabric-samples -> test-network -> organizations -> peerOrganizations -> org1.example.com -> users -> Admin@org1.example.com -> msp -> keystore -> priv_sk。
client
應新增到的物件是:
"clientPrivateKey": {
"path": "../fabric-samples/test-network/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/keystore/priv_sk"
}
另外,在client
物件下新增另一個名為clientSignedCert
的屬性,並在該屬性下新增一個名為path
的屬性,該屬性具有一個字串變數,該變數指向標識的簽名證書。再次注意,提供的路徑是相對於工作區的。在本例中,它位於fabric-samples -> test-network -> organizations -> peerOrganizations -> org1.example.com -> users -> Admin@org1.example.com -> msp -> signedcerts -> admin@org1.example.com-cert.pem
client
應新增到的物件是:
"clientSignedCert": {
"path": "../fabric-samples/test-network/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/signcerts/Admin@org1.example.com-cert.pem"
}
clients
物件現在應該如下所示:
"clients": {
"Admin@org1.example.com": {
"client": {
"organization": "Org1",
"connection": {
"timeout": {
"peer": {
"endorser": "300"
}
}
},
"credentialStore": {
"path": "tmp/hfc-kvs/org1",
"cryptoStore": {
"path": "tmp/hfc-kvs/org1"
}
},
"clientPrivateKey": {
"path": "../fabric-samples/test-network/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/keystore/priv_sk"
},
"clientSignedCert": {
"path": "../fabric-samples/test-network/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/signcerts/Admin@org1.example.com-cert.pem"
}
}
}
}
通道物件
在建立與Fabric網路的連線時,Caliper的織物聯結器需要幫助。必須提供一個channels
物件,該物件列出可能與之互動的智慧合約。
將由test-network
建立的已知通道mychannel
新增到Caliper網路組態檔的channels
部分,並賦予它一個布林值true建立的屬性。我們必須將此通道上可用的智慧合約列為名為contracts
的陣列中的物件。每個智慧合約物件都有兩個屬性,id
和version
。id
指定合同ID;在本例中,它是basic
。版本是特定的合同版本;在本例中是1.0.0
。將其作為陣列中的一個物件新增,以使Caliper網路組態檔中的結果通道物件變為:
"channels": {
"mychannel": {
"created" : true,
"contracts": [
{
"id":"basic",
"version":"1.0.0"
}
]
}
}
Caliper網路組態檔現在應該完全填充。花點時間檢查並確保證書和金鑰的路徑是正確的,這是很有用的。
{
"version" : "1.0",
"name": "Caliper test",
"caliper" : {
"blockchain": "fabric"
},
"clients": {
"Admin@org1.example.com": {
"client": {
"credentialStore": {
"path": "/tmp/org1",
"cryptoStore": {
"path": "/tmp/org1"
}
},
"organization": "Org1",
"clientPrivateKey": {
"path": "../fabric-samples/test-network/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/keystore/priv_sk"
},
"clientSignedCert": {
"path": "../fabric-samples/test-network/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/signcerts/Admin@org1.example.com-cert.pem"
},
"connection": {
"timeout": {
"peer": {
"endorser": "300"
}
}
}
}
}
},
"channels": {
"mychannel": {
"created" : true,
"contracts": [
{
"id":"basic",
"version":"1.0.0"
}
]
}
},
"organizations":{
"Org1": {
"mspid": "Org1MSP",
"peers": [
"peer0.org1.example.com"
]
}
},
"peers": {
"peer0.org1.example.com": {
"url": "grpcs://localhost:7051",
"tlsCACerts": {
"pem": "-----BEGIN CERTIFICATE-----\n<UNIQUE CONTENT>\n-----END CERTIFICATE-----\n"
},
"grpcOptions": {
"ssl-target-name-override": "peer0.org1.example.com",
"hostnameOverride": "peer0.org1.example.com"
}
}
}
}
在基準測試期間,工作負載模組與部署的智慧合約進行互動。workload模組從Caliper-core
擴充套件了Caliper類WorkloadModuleBase
。工作負載模組提供三個覆蓋:
initializeWorkloadModule
-用於初始化基準測試所需的任何項submitTransaction
-用於在基準的監視階段與智慧合約方法互動cleanupWorkloadModule
—用於在完成基準測試後進行清理有關更多資訊,請參閱左側選單上有關工作負載設定的特定檔案。
我們將推動的工作負載旨在對世界狀態資料庫中現有資產的查詢進行基準測試。因此,我們將使用workload模組中提供的所有三個階段:
initializeWorkloadModule
-建立可在submitTransaction階段查詢的資產submitTransaction
-查詢在initializeWorkloadModule階段建立的資產cleanuWorkloadModule
-用於移除在initializeWorkloadModule階段建立的資產,以便可以重複基準測試在workload資料夾中,建立一個名為readAsset.js的檔案,其中包含以下內容:
'use strict';
const { WorkloadModuleBase } = require('@hyperledger/caliper-core');
class MyWorkload extends WorkloadModuleBase {
constructor() {
super();
}
async initializeWorkloadModule(workerIndex, totalWorkers, roundIndex, roundArguments, sutAdapter, sutContext) {
await super.initializeWorkloadModule(workerIndex, totalWorkers, roundIndex, roundArguments, sutAdapter, sutContext);
}
async submitTransaction() {
// NOOP
}
async cleanupWorkloadModule() {
// NOOP
}
}
function createWorkloadModule() {
return new MyWorkload();
}
module.exports.createWorkloadModule = createWorkloadModule;
填充此檔案時,我們參照已部署智慧合約中的可用方法資產轉讓可在以下位置找到的檔案:fabric-samples -> asset-transfer-basic -> chaincode-javascript -> lib -> assetTransfer.js
填充initializeWorkloadModule
此方法用於在基準完成時準備主submitTransaction
方法所需的任何項。
要建立的資產數量將給出如下roundArguments.assets
。我們通過填充arguments物件(定義交易體)和使用Caliper API sendRequests
(需要了解以下知識)來建立資產:
方法應該如下所示:
async initializeWorkloadModule(workerIndex, totalWorkers, roundIndex, roundArguments, sutAdapter, sutContext) {
await super.initializeWorkloadModule(workerIndex, totalWorkers, roundIndex, roundArguments, sutAdapter, sutContext);
for (let i=0; i<this.roundArguments.assets; i++) {
const assetID = `${this.workerIndex}_${i}`;
console.log(`Worker ${this.workerIndex}: Creating asset ${assetID}`);
const request = {
contractId: this.roundArguments.contractId,
contractFunction: 'CreateAsset',
invokerIdentity: 'Admin@org1.example.com',
contractArguments: [assetID,'blue','20','penguin','500'],
readOnly: false
};
await this.sutAdapter.sendRequests(request);
}
}
在上面的範例中,將建立具有相同引數的不同資產(blue,20,penguin,500)。將上述內容與智慧合約方法本身相比較,可以明顯看出,契約引數與方法引數之間存在1:1的對映關係。
填充submitTransaction
此方法在基準測試階段重複執行。我們將通過查詢在initializeWorkloadModule
方法中建立的資產來評估ReadAsset
智慧合約方法。
首先,為要查詢的資產建立一個字串標識,該標識由worker索引和一個介於0和已建立資產數量之間的隨機整數串聯而成。
然後等待對sendRequests
的呼叫,傳遞一個物件,該物件包含:從round引數傳入的contractId
集;設定為ReadAsset
的contractFunction
;設定為invokerIdentity
的admin@org1.example.com
;和chaincodeArguments
設定為一個陣列,其中包含要在此執行中查詢的資產。
方法應該如下所示:
async submitTransaction() {
const randomId = Math.floor(Math.random()*this.roundArguments.assets);
const myArgs = {
contractId: this.roundArguments.contractId,
contractFunction: 'ReadAsset',
invokerIdentity: 'Admin@org1.example.com',
contractArguments: [`${this.workerIndex}_${randomId}`],
readOnly: true
};
await this.sutAdapter.sendRequests(myArgs);
}
填充cleanupWorkloadModule
此函數用於在測試後進行清理,因為它通過使用智慧合約函數DeleteAsset
刪除在initializeWorkloadModule
函數中建立的資產。該實現類似於initializeWorkloadModule
中的實現。注意可以重構initializeWorkloadModule
和cleanupWorkloadModule
,以使用執行建立/刪除操作的通用方法,這將留給感興趣的讀者。
async cleanupWorkloadModule() {
for (let i=0; i<this.roundArguments.assets; i++) {
const assetID = `${this.workerIndex}_${i}`;
console.log(`Worker ${this.workerIndex}: Deleting asset ${assetID}`);
const request = {
contractId: this.roundArguments.contractId,
contractFunction: 'DeleteAsset',
invokerIdentity: 'Admin@org1.example.com',
contractArguments: [assetID],
readOnly: false
};
await this.sutAdapter.sendRequests(request);
}
}
現在應該完全填充測試回撥檔案:
'use strict';
const { WorkloadModuleBase } = require('@hyperledger/caliper-core');
class MyWorkload extends WorkloadModuleBase {
constructor() {
super();
}
async initializeWorkloadModule(workerIndex, totalWorkers, roundIndex, roundArguments, sutAdapter, sutContext) {
await super.initializeWorkloadModule(workerIndex, totalWorkers, roundIndex, roundArguments, sutAdapter, sutContext);
for (let i=0; i<this.roundArguments.assets; i++) {
const assetID = `${this.workerIndex}_${i}`;
console.log(`Worker ${this.workerIndex}: Creating asset ${assetID}`);
const request = {
contractId: this.roundArguments.contractId,
contractFunction: 'CreateAsset',
invokerIdentity: 'Admin@org1.example.com',
contractArguments: [assetID,'blue','20','penguin','500'],
readOnly: false
};
await this.sutAdapter.sendRequests(request);
}
}
async submitTransaction() {
const randomId = Math.floor(Math.random()*this.roundArguments.assets);
const myArgs = {
contractId: this.roundArguments.contractId,
contractFunction: 'ReadAsset',
invokerIdentity: 'Admin@org1.example.com',
contractArguments: [`${this.workerIndex}_${randomId}`],
readOnly: true
};
await this.sutAdapter.sendRequests(myArgs);
}
async cleanupWorkloadModule() {
for (let i=0; i<this.roundArguments.assets; i++) {
const assetID = `${this.workerIndex}_${i}`;
console.log(`Worker ${this.workerIndex}: Deleting asset ${assetID}`);
const request = {
contractId: this.roundArguments.contractId,
contractFunction: 'DeleteAsset',
invokerIdentity: 'Admin@org1.example.com',
contractArguments: [assetID],
readOnly: false
};
await this.sutAdapter.sendRequests(request);
}
}
}
function createWorkloadModule() {
return new MyWorkload();
}
module.exports.createWorkloadModule = createWorkloadModule;
基準組態檔定義基準輪次並參照定義的工作負載模組。它將指定在生成負載時要使用的測試工作者的數量、測試輪的數量、每輪的持續時間、在每輪期間應用於交易負載的速率控制以及與監視器相關的選項。本教學不會使用任何可用的監視器或交易觀察程式;有關這些詳細資訊,請參閱檔案。
基準組態檔可能以yaml或json格式提供:這裡我們將使用yaml格式。請注意,yaml檔案區分大小寫,所有標籤都是小寫。
基準組態檔有一個必需的節:
test:
在benchmarks資料夾下建立一個名為myAssetBenchmark.yaml包括以下內容:
test:
name: basic-contract-benchmark
description: A test benchmark
workers:
rounds:
test:包含基準測試資訊的根級塊。
name:測試的名稱,在本例中為「基本合同基準」。
description:對基準的描述,在本例中為「測試基準」。
workers:一組鍵,用於定義後續基準中使用的worker(獨立的worker使用者端範例)的數量。
rounds:將按順序進行的不同測試回合的陣列。輪次可用於對不同的智慧合約方法進行基準測試,或以不同的方式對同一方法進行基準測試。
現在,我們將填充模板檔案以指定工作人員的數量以及使用我們建立的工作負載模組的測試回合。
填充workers
我們將使用兩個單獨的工人,這是通過工人規範完成的:
type: local
number: 2
填充rounds
每個round塊包含以下內容:
label
- 用於回合的唯一標題標籤。description
- 正在執行的回合的描述。txDuration
- 測試持續時間的規範,以秒為單位rateControl
- 一種速率控制型別,帶有選項。workload
- 要使用的工作負載模組,帶有要傳遞給模組的引數。傳遞的所有引數都可以作為roundArguments
在workload模組中使用。我們將指定一個標記為readAsset
的基準輪,並使用description Query asset benchmark
執行30秒,使用一個fixed-load
速率控制器來保持2的恆定交易壓力。此外,我們將提供一個工作負載通過規範我們的readAsset.js
工作負載檔案,我們將傳遞引數{assets:10,compactId:asset-transfer-basic}
。
以上是通過round規範來實現的:
- label: readAsset
description: Read asset benchmark
txDuration: 30
rateControl:
type: fixed-load
opts:
transactionLoad: 2
workload:
module: workload/readAsset.js
arguments:
assets: 10
contractId: basic
完整的基準組態檔
現在應該完全填充基準組態檔:
test:
name: basic-contract-benchmark
description: test benchmark
workers:
type: local
number: 2
rounds:
- label: readAsset
description: Read asset benchmark
txDuration: 30
rateControl:
type: fixed-load
opts:
transactionLoad: 2
workload:
module: workload/readAsset.js
arguments:
assets: 10
contractId: basic
我們現在可以使用上面的組態檔和測試模組來執行效能基準測試了。效能基準測試將使用Caliper CLI執行,需要提供一個指向工作區的路徑,以及指向網路組態檔和基準組態檔的工作區相對路徑。這些資訊分別與標記--caliper workspace
、--caliper-networkconfig
和--caliper benchconfig
一起提供。
由於智慧合約已經安裝和範例化,Caliper只需要執行測試階段。這是通過使用--caliper-flow-only-test
標誌來指定的。
由於目標網路已啟用發現功能,我們可以通過使用標誌--capiler Fabric gateway enabled
和--capiler Fabric gateway discovery
來使用Hyperledger Fabric閘道器。
執行命令
確保您位於Caliper工作區目錄中。
在終端中,執行以下Caliper CLI命令:
npx caliper launch manager --caliper-workspace ./ --caliper-networkconfig networks/networkConfig.json --caliper-benchconfig benchmarks/myAssetBenchmark.yaml --caliper-flow-only-test --caliper-fabric-gateway-enabled --caliper-fabric-gateway-discovery
基準測試結果
結果報告將詳細說明每輪基準測試的以下專案:
您已經成功地為智慧合約執行基準效能測試。您可以通過改變基準測試引數來重複測試,以及新增資源監視器。有關全套選項,請參閱Caliper檔案。
參考自官方檔案
如有侵權,請聯絡作者刪除,謝謝!
If there is infringement, please contact the author to delete, thank you!