實驗目標：
在solo模式下，測試fabric效能測試，得出每秒最大交易筆數
基於fabric v1.0.5版本
壓力測試工具ab
centos下安裝 yum -y install httpd-tools
實驗環境：
採用fabric的go語言sdk對區塊鏈進行操作,利用beego封裝sdk,對外提供http請求介面
以e2e實驗構建區塊鏈網路
一．系統吞度量要素：
乙個系統的吞度量（承壓能力）與request對cpu的消耗、外部介面、io等等緊密關聯。
單個reqeust 對cpu消耗越高，外部系統介面、io影響速度越慢，系統吞吐能力越低，反之越高。
系統吞吐量幾個重要引數：qps（tps）、併發數、響應時間
qps（tps）：每秒鐘request/事務 數量
併發數： 系統同時處理的request/事務數
（很多人經常會把併發數和tps理解混淆）
理解了上面三個要素的意義之後，就能推算出它們之間的關係：
qps（tps）= 併發數/平均響應時間
乙個系統吞吐量通常由qps（tps）、併發數兩個因素決定，每套系統這兩個值都有乙個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、記憶體等等其它消耗導致系統效能下降。
決定系統響應時間要素
我們做專案要排計畫，可以多人同時併發做多項任務，也可以乙個人或者多個人序列工作，始終會有一條關鍵路徑，這條路徑就是專案的工期。
系統一次呼叫的響應時間跟專案計畫一樣，也有一條關鍵路徑，這個關鍵路徑是就是系統影響時間；
關鍵路徑是有cpu運算、io、外部系統響應等等組成。
二．系統吞吐量評估：
我們在做系統設計的時候就需要考慮cpu運算、io、外部系統響應因素造成的影響以及對系統效能的初步預估。
而通常境況下，我們面對需求，我們評估出來的出來qps、併發數之外，還有另外乙個維度：日pv。
通過觀察系統的訪問日誌發現，在使用者量很大的情況下，各個時間週期內的同一時間段的訪問流量幾乎一樣。比如工作日的每天早上。只要能拿到日流量圖和qps我們就可以推算日流量。
通常的技術方法：
1. 找出系統的最高tps和日pv，這兩個要素有相對比較穩定的關係（除了放假、季節性因素影響之外）
2. 通過壓力測試或者經驗預估，得出最高tps，然後跟進1的關係，計算出系統最高的日吞吐量。b2b中文和**面對的客戶群不一樣，這兩個客戶群的網路行為不應用，他們之間的tps和pv關係比例也不一樣。
效能測試 效能測試步驟
針對此次庫內作業效能測試，梳理一下期間的工作流程 梳理已有的介面指令碼，確認需要做效能測試的幾個介面，即使用率高，對效能有要求的幾個主要介面。結合頁面的操作，和確認的介面，梳理具體的業務邏輯 同時，請開發人員部署了測試環境。測試環境的伺服器指標，盡量和生產環境一致。部署的時候，負載均衡等情況也盡量和...
效能測試之前端效能測試
本次總結總共分為以下部分 1.如何衡量乙個系統是否要做壓測 2.壓測的準備過程 3.壓測工具選擇 4.壓測資料以及報告結果相關 1.如何衡量乙個系統是否要做壓測 首先需要衡量乙個系統是否需要壓測，從以下角度考慮 從兩個角度進行分析 a.業務角度 明確系統是對內使用還是對外使用，使用人數是多少，如果使...
Fabric學習 Fabric整體專案結構介紹
參考版本較低，建議去看高版本手冊。bccsp 提供了加密標準以及演算法的實現，為整個專案提供統一的加密 簽名 驗籤服務。common common模組提供了通用功能以及一些通用的 實現，包括日誌 錯誤 工具包等，主要包括專案全域性的功能性 core core模組為fabric專案的核心 模組，其中包...