当一切正常时，您通常不会担心区块链     测试   。我们将在下面解释为什么最好不要搁置性能评估，使用什么度量标准并充分利用它才是最好的。就让我们一探究竟吧。

“每秒交易数”（ TPS）

在分布式系统中，TPS是一个非常模糊和反复无常的度量。

TPS     测量   来自分布式     数据库   。它们通常使用标准化的交易类型或集合（例如，一些插入、更新、删除以及常量选择数）来执行，并针对特定的集群或单独的机器进行配置。这样的“综合”指标并不能反映出所讨论的数据库或区块链的实际性能，因为在这样的系统中，交易处理时间可能会有所不同。

面向共识性的数据库（请参阅“CAP-theorem”）在从其他节点接收到足够数量的确认之前不会提交交易——这是很慢的。

面向可用性的数据库时，如果交易被简单地写入磁盘，那么它就是成功的。他们立即提供更新的数据——这是非常快的（尽管这个交易可能在将来回滚）。如果交易只更新一个数据单元，则TPS将更高。如果交易更新许多数据单元（行、索引、文件），它们将彼此阻塞。

这就是为什么我们在Oracle、MSSQL、PostgreSQL和MongoDB、Redis、Tarantool之间看不到任何“TPS竞争”的原因——它们的内部机制和任务差别很大。

在我们看来，“测量区块链TPS”是指进行全面的性能测量：

a）在可重复的条件下

b）具有接近实际的块验证器数量

c）使用不同类型的交易：

-研究区块链的典型情况（例如，主要加密货币的transfer （））

-加载     存储   子系统（每个交易都有相当大的变化）

-加载网络带宽（大交易大小）

-     cpu   加载（大规模密码转换或计算）

要讨论我们所珍视的“每秒交易数”，您需要描述所有网络条件、参数和基准测试逻辑。在区块链中，将交易应用到某个内部数据库并不意味着共识会接受它。

在PoW共识中，交易永远不会最终确定。如果一个交易包含在一台机器上的一个块中，这并不意味着它将被整个网络接受（例如，另一个分叉获胜的情况）。

如果区块链有一个额外的算法来确保终结性（如EOS、Ethereum 2.0、Polkadot parach     ai   ns使用与祖父终结性一共识的方式），那么处理时间可以视为节点看到交易和下一个完成块的时间。这样的TPS是非常有用的，但是因为它们比预期的要低，所以很少见。

TPS涉及到很多东西。保持怀疑，询问细节。

Blockchain-spec     if   ic指标

本地TPS

处理交易的数量和最大/平均/分钟处理时间（在本地节点上）是非常方便测量的，因为执行这些操作的函数通常用代码表示。交易处理时间等于更新状态数据库所需的时间。例如，在“乐观”区块链中，已处理的交易可能已经经过验证，但还没有被一致接受。在这种情况下，节点将更新后的数据发送到客户机（假设不会有任何链分叉。

这个度量不是很可靠：如果选择另一个链分支作为主分支，那么关于交易的统计数据也必须回滚。在测试中，这一点常常被忽略。

“我们的区块链昨天收到了8000个tps”。这些数字通常可以在简短的项目报告中找到，因为它们很容易测量。只需一个运行节点和一个加载脚本就足够了。在这种情况下，没有网络延迟会降低达成网络共识的速度。

该指标反映了状态数据库在不受网络影响的情况下的性能。这个数字并没有反映真实的网络带宽，但是显示了如果共识和网络足够快，它将努力达到的极限。任何区块链交易的结果都是多个原子存储写。例如，一个     比特币   支付交易涉及删除几个旧的UTXOs（删除）和添加新的UTXOs（插入）。在以太坊中，执行一个小型智能合约代码并更新几个键-值对。

原子存储写是发现存储子系统瓶颈和区分低级逻辑问题和内部逻辑问题的优秀指标。

区块链节点可以用几种编程语言实现——这更可靠。例如，以太坊节点有Rust和Go实现。在测试网络性能时请记住这一点。

本地生产的区块数量

这个简单的指标显示了某个验证器生成的块的数量。它依赖于共识，并且对于评估单个验证者网络的“有用性”至关重要。

因为验证器在每个块上都能赚钱，所以它们负责机器的稳定运行和安全。您可以确定哪个验证器候选是最合格的、受保护的，并且准备好在具有真实用户资产的公共网络中工作。公制值可以公开检查—只需下载区块链并计算块的数量。

最后结尾и不可逆转的块

终局性确保在区块链中包含的所有交易都不会回滚，也不会被另一个链分叉替换。这是PoS网络防止双重消费攻击和为用户确认加密货币交易的一种方式。

当有一个块完成包含该交易的链时，而不是当某个交易被节点接受时，用户认为该交易是最后块。要完成一个块，验证器必须在p2p网络中接收这个块并相互交换签名。这里检查区块链的实际速度，因为交易完成的时刻对用户来说是最重要的。

终结性算法也不同，它会相交并结合主要共识（阅读：Casper在Ethereum，最后不可逆块在EOS，外公在奇偶Polkadot和他们的修改，例如，     Mi   xBy     te   s RANDPA）。

对于没有完成所有块的网络，一个有用的度量是在最后完成的块和当前最新的块之间的延迟。这个数字显示了验证器落后了多少，这与正确的链一致。如果差距很大，那么最终性算法需要额外的分析和优化。

P2P层

点对点子系统——区块链网络的中间层——经常被忽略。这都要归咎于块交付和验证器之间交易的模糊延迟。

当确认器的数量很少的时候，它们是本地化的，对等列表是硬编码的，一切都工作得很好而且很快。但是，就像验证器存在一样，节点在地理上是分布的，丢失的数据是模拟的，我们正面临严重的“tps”故障。

例如，当使用附加的终结性算法测试EOS共识性时，将验证器的数量增加到80-100台，分布在四大洲，对终结性几乎没有影响。与此同时，增加的包丢失严重影响了最终结果，这证明了需要额外的p2p层配置来更好地抵抗网络包丢失（而不是高延迟）。不幸的是，有许多不同的设置和因素，只有基准测试允许我们了解所需的验证器数量，并获得相当舒适的区块链速度。

p2p子系统的配置从文档中很清楚，例如，看看［libp2p］、［Kademlia］协议或［BitTorrent］。

重要的p2p指标可以是：

· 进出流量

· 与其他对等点的成功/不成功连接的数量

· 返回先前缓存的数据块的次数，以及为了找到所需的数据块需要进一步转发请求的次数（缓存命中/丢失模拟数据）

例如，在访问数据时，较大的遗漏数意味着只有少数节点拥有请求的数据，而它们没有时间将这些数据分发给每个节点。接收/发送的p2p通信量允许识别处理网络配置或通道问题的节点。

区块链节点的系统度量

区块链节点的标准系统度量在大量的源代码中都有描述，因此我们将简要介绍。它们有助于发现逻辑瓶颈和错误。

中央处理器

CPU显示处理器执行的计算量。如果CPU负载高——节点正在计算一些东西，积极使用逻辑或FPU（几乎从未在区块链中使用）。例如，后一种情况会发生，因为节点正在检查电子签名、使用强密码处理事务或进行复杂的计算。

CPU可以被划分成更多指向代码瓶颈的指标。例如，系统时间—花在内核代码上的时间，用户时间—花在用户进程上的时间，io—等待来自慢速外部设备（磁盘/网络）的     i/o   ，等等。

内存

现代区块链使用键值数据库（LevelDB、RocksDB），这些数据库不断地在其内存中存储“热”数据。任何加载的服务都会受到由错误或针对节点代码的攻击所导致的内存泄漏的影响。如果内存消耗正在增加或急剧增加，很可能是由于大量的状态数据库键、大型交易队列或不同节点子系统之间的消息量增加造成的。

内存负载不足表明可能会增加块数据限制或最大化交易复杂性。

响应网络客户机的完整节点依赖于文件缓存指标。当客户机访问状态数据库和交易日志的各个部分时，可能会出现磁盘中的旧块并替换新块。这反过来又降低了客户机的响应速度。

网络

主要的网络指标是流量的大小（以字节为单位）、发送和接收网络数据包的数量、丢包率。这些指标经常被低估，因为区块链还不能以每秒1 Gbit的速度处理交易。

目前，一些区块链项目允许用户共享WiFi或提供存储和发送文件或消息的服务。在测试这样的网络时，网络     接口   流量的数量和质量变得非常重要，因为一个拥挤的网络通道会影响机器上的所有其他服务。

存储

磁盘子系统是所有服务中最慢的组件，常常会导致严重的性能问题。过多的日志记录、意外的备份、不方便的读/写模式、大量的区块链卷——所有这些都可能导致显著的节点减速或过多的硬件需求。

使用磁盘的区块链交易日志操作模式类似于使用写前日志（WAL）的不同DBMS。从技术上讲，交易日志可以被看作是状态数据库的WAL。

因此，这些存储指标非常重要，因为它们可以确定现代键值数据库中的瓶颈。读取/写入IOPS数、最大/最小/avg延迟以及许多其他有助于优化磁盘操作的指标。

结论

综上所述，我们可以将度量分为：

· 区块链节点度量（产生的块的数量、处理的事务的数量、处理时间、完成时间等）

· p2p子系统指标（命中/丢失请求的数量、活动对等点的数量、p2p流量的数量和结构等）

· 系统节点指标（cpu、内存、存储、网络等）

每个组都很重要，因为一旦子系统错误，就会限制其他组件的操作。即使是少量验证器的减速也会严重影响整个网络。

在共识性和终结性算法中，最棘手的错误只出现在大型交易流或共识性参数更改时。他们的分析需要可重复的测试条件和复杂的负载场景。

责任编辑：ct