超分类账TPS
我正在做一个基于Hyperledger的概念证明(PoC)，并将其与医疗保健数据集成(这是一个学术项目)。
我遵循了本教程：https://github.com/IBM/BlockchainNetwork-CompositeJourney
由于我是一个Windows用户，我的SSD上没有可用的空间来容纳Linux双引导和所有分类账内容，所以我决定使用"Oracle“上的所有POC安装，将所有VM文件(*.vdi)托管在我的辅助硬盘上，即HDD，而不是SSD。
这是一个棘手的部分，"Oracle“软件本身安装在我的SSD中，但是带有所有POC的Linux都在HDD上，这是我的第二个硬盘驱动器。
到目前为止，我已经让Peer在我的VM上工作，并且已经将数据保存在上面。我关心的是它的表现.
我已经在python中创建了代码片段来对其进行基准测试，并且我得到了每个事务在2到3秒之间的fabric响应，我认为这是一个非常低的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)回答 2
Stack Overflow用户
发布于 2019-02-15 11:41:45
造成TPS低的因素很多。要在Hyperledger Fabric中进行交易，这需要经过几个过程。
1)创建交易提案，并将其发送给所有同行的批注。例如，如果您有下一个政策批注：
AND('Org1MSP','Org2MSP') 每个组织中至少有一个对等方需要对事务进行批注，对于发送的每个对等点，它们将在容器内执行事务，并检查它是否有效，如果它有效，它们将响应状态200 (这是针对每个人，个别的)。
2)下一步是将交易比例发送给订货者，如果是单订购者协商一致比卡夫卡-订货者协商一致(你可以在这里检查它的工作原理。)快。订购者将创建该块并等待几秒钟，然后将其发送到每个orgs锚对等点。这几秒钟它是configtx.yaml文件中一个非常重要的参数，这是BatchTimeout，我将引用超级分类账结构的官方站点的定义：
批量超时。在第一个事务到达之后等待额外事务的时间，然后再切割一个块。减少此值将改善延迟，但过低可能会降低吞吐量，因为不允许块填充到其最大容量。
编辑:默认情况下，batchTimeout值为其2秒。
3)现在，命令者将该块发送给所有主播对等点，并将该块广播给其所属组织的所有对等方，完成该块并更新分类账的状态。
当然，如果您的计算机有一个低性能，这一过程将更加缓慢。
Stack Overflow用户
发布于 2019-08-21 08:29:24
一般来说，织物中的TPS取决于各种因素。
- 背书政策(认可节点和策略的数量)
- 当前状态数据库(级DB，Couch DB)
- 资源分配(硬件配置)
- 块大小(批处理大小和批处理时间(在configtx.yaml文件中定义)和更多的因素
网络能够处理的事务数和事务延迟是两件不同的事情。从发送事务到获得响应之间的时间是一个延迟，要执行的事务数量最多，其次是TPS。
https://stackoverflow.com/questions/54702112
复制相似问题
腾讯云开发者
