应用系统性能提升的关键在于运维端的接入管理模型（AAA，认证 Authentication、授权 Authorization、计费 Accounting）及业务端的并发（Concurrency）/ 吞吐量(Throughput) 模型。
区块链是典型的“运维友好型”系统，天然的自我治理能力极大程度上优化了接入管理模型，但现有区块链系统的并发 / 吞吐量模型指标却饱受诟病。无论是 BTC 的 7tps，还是 ETH 的 40tps 在传统业务系统动辄万级甚至十万级 tps 面前都难以抬头。
区块链项目的需求：
聚焦底层基础设施，项目自身行业或领域特征不明显，易引入本行业业务；
能够实现微服务级部署，扩容友好，易迁移部署；
PARABOX 项目6 月伊始发布测试网，现有的区块链系统业务处理能力普遍面向价值传递进行建设，因此对于区块链系统性能的评测思路应面向交易过程展开。测试网初期（即目前）提供主链并行计算模块的测试验证。
Transaction，区块链圈的人通常叫“交易”，可能是 BTC 白皮书翻译传承下来的吧。软件测评应充分考虑软件质量体系的要求，同理，对于一个区块链底层架构而言，模拟价值传输压力的交易激励能够作为区块链底层基础设施 tps 指标的验证形式。
据此，先定义一个原子事务作为本次测试验证的基本测试用例——“合约转账”。1 次“合约转账”包括 2 次读 2 次写操作，具体步骤如下：
从 A 账户读取余额（1 次读）；
从 B 账户读取余额（1 次读）；
从 A 账户减去金额（1 次写）；
从 B 账户增加金额（1 次写）。
小编因之前接触过 BTC，深深叹服中本聪大神 UTXO 体系设置的精妙，但传统应用系统往往还是依赖账户模型体系，因此选用一个经典的原子转账事务作为标准测试用例，并以该用例的执行效率作为吞吐量指标的依据。PARABOX 支持区块链智能合约，上述原子事务须编写为合约脚本部署至测试网。进而，再定义一个基本的测试流程梗概：
该测试流程可作为一个典型的区块链性能测评策略。以一次“合约转账”为一个基本业务执行单元，编写运行于区块链平台上的“合约脚本”程序，该程序能够被区块链系统各节点部署并执行。实施测评前需依据特定的用例或随机生成测试用例初始化测试数据，不同场景、不同轮次的测评实施须基于相同的测试数据以确保测试结果可信。继续定义不同的测试场景：
场景 I：单机场景，1 业务处理节点 +1 业务数据集；
场景 II：集群 - 单机场景，N 业务处理节点 +1 业务数据集；
场景 III：分布式集群场景，N 业务处理节点 +N 业务数据集。
单机场景旨在验证区块链系统的独立性能，因区块链为分布式集群系统，针对单机场景测评验证对于最终全网性能指标结论的意义不是很大，但有助于我们更好地定义集群测试的边界。如单机测评的性能指标为P，进行集群测评时能够以 P 为基础通过节点 / 进程增长与性能指标增长之间的关系判定是否有必要进行更大规模的测评验证。
此外，在单机测试的过程中通过补充带有网络延迟的测试环境有助于对网络环境影响因素进行基本的定量。
集群- 单机场景旨在针对面向区块链底层平台所支撑的实际业务类型进行覆盖性测试。区块链技术本身是去中心化的，但区块链系统所支撑的上层业务可能有中心化特征，因此需要进行多对一场景的模拟测评。该场景的设计针对数据 I/O 存在固定瓶颈的情况下对区块链系统业务处理吞吐量进行定量测评。
分布式集群场景旨在针对处于P2P 网络拓扑中交易执行处理与交易数据协同均需实现区块链共识的业务场景进行覆盖性测试。该场景为典型的区块链系统场景，通过单机场景及集群 - 单机场景的测评，能够辅助我们对该场景下的测试边界及测试差异性因子进行综合分析，确定测试实施的方式及被测部署环境的典型性，从而得到较为可靠的测评结论。
区块链系统的运行有多个层次，区块链程序可被部署至多台服务器（Server），每台服务器可运行多个进程级实例（Worker），对PARABOX 而言，每个实例内可以配置多个并行化业务单元（Actor）。因此性能指标 TPS 受服务器、进程、业务单元的影响均需在测试中体现，最优 TPS 测评结果应表现在一个适宜的服务器、进程、业务单元配置之下，在测试条件允许之内寻找这个最优的配置也是本次测评的目的之一。
综上，拟实现的测试验证目的包括但不限于单服务节点运行状态下的并发执行能力及集群环境下的性能延展性。
对PARABOX测试网进行开发接入的核心是厘清Benchmark 环境，详细运行代码请在第二、第三篇查看。
通过测试验证的执行结果基本能够看出随着系统的扩容，吞吐量性能指标的增长是较为健康的，测试范围之内预期最优指标约为1.3w~1.5w tps。此外，在每一组特定的部署模式下，能够通过系统调优获得平均约 10%~15% 的性能提升，吞吐量性能曲线的极值点符合较为合理，符合快升缓降的泊松分布。