超级账本 TPS

Question

我正在做一个基于 Hyperledger 区块链的概念证明 (PoC)，并将其与医疗保健数据集成（这是一个学术项目）。

我遵循了这个教程：https://github.com/IBM/BlockchainNetwork-CompositeJourney

由于我是 Windows 用户，我的 SSD 上没有剩余空间来容纳带有所有分类帐内容的 Linux Ubuntu 双启动，我决定在具有所有 VM 的“Oracle VM VirtualBox”上安装所有 POC文件 (*.vdi) 托管在我的辅助硬盘驱动器上，它是 HDD，而不是 SSD。

这是棘手的部分，“Oracle VM VirtualBox”软件本身已完美安装在我的 SSD 中，但具有所有 POC 的 Linux VM 位于 HDD 上，这是我的辅助硬盘驱动器。

到目前为止，我已经让 Peer 在我的 VM 上工作，并且已经在其上保存了数据。我的问题/担忧是关于它的表现......

我在 python 中创建了一个 sn-p 代码来对其进行基准测试，每个事务的结构响应时间在 2 到 3 秒之间，我认为这是极低的 TPS（每秒事务数），对吧？

我做错了吗？我一步一步按照教程进行操作，它可以工作，但 TPS 性能极低。

可能是因为我让它在带有 Oracle VM 的 HDD 上工作？

如果我直接在带有 Linux 的 SSD 上运行它，我会获得更好的 TPS 吗？

 //composer-rest-server endpoint
 url = 'http://localhost:3000/api/Member'

 start = time.time()
 response = requests.post(url, headers=headers, data=data)
 end = time.time()
 timeTotal = (end - start)

Answer 1

通常，织物中的 TPS 取决于多种因素。

1. 背书策略（背书节点和策略的数量）
2. 当前状态数据库（Level DB、Couch DB）
3. 资源分配（硬件配置）
4. 块大小（批处理大小和批处理时间（在 configtx.yaml 文件中定义））和更多因素

网络可以处理的事务数量和事务延迟是两个不同的东西。 发送事务和获得响应之间的时间是延迟 每秒执行的最大事务数是 TPS

Answer 2

TPS 低的因素很多。要在 Hyperledger Fabric 中进行交易，需要经过几个过程。

1) 创建交易提案并将其发送给所有对等方背书。例如，如果您有下一个政策背书：

AND('Org1MSP','Org2MSP')  

每个组织的至少一个peer需要对交易进行背书，对于您发送提案的每个peer，他们将在容器内执行交易并检查其是否有效，如果有效，他们将响应状态200 （这是针对每个人的，个人的）。

2) 下一步是将交易提案发送给orderer，如果是solo-orderer 共识将比kafka-orderer 共识(You can check how it works here) 快。 orderer 将创建块并等待几秒钟，然后将其发送给每个 orgs ancho peers。这几秒是configtx.yaml文件中一个很重要的参数，这个是BatchTimeout，我引用hyperledger fabric官网的定义：

批处理超时。第一次交易后等待的时间 在切割一个块之前到达额外的交易。递减 此值将改善延迟，但降低太多可能 通过不允许块填充到最大值来降低吞吐量 容量。

Here you can read more.

编辑：默认情况下，batchTimeout 值为2sec。

3) 现在，orderer 会将区块发送给所有 ancho peer，他们会将区块广播给他们所属组织的所有 peer，提交区块并更新账本的状态。

当然，如果你的电脑性能低，这个过程会更慢。