Kin系统急需一个交易确认时间和费率可以预见的区块链系统，恒星是我们的获胜候选方案。
现在，我们为Kin使用Kik九年的网络工程经验和知识检验恒星公开区块链网络。我们的目标是：看看恒星是否真的符合性能要求。
简而言之
测试结果很好。
既然你已经平静下来了，让我们进入细节。
对于结果需要做好准备活动。
需求
首先，简单介绍下压力测试。根据维基百科介绍：
压力测试是将需求在提到软件系统或计算设备测试它的响应。压力测试是在正常和预期的峰值负荷条件下确定系统的行为。它有助于识别应用程序的最大操作能力以及任何瓶颈，并确定哪些因素导致了失败。
在我们的案例中，要测试的系统是恒星公共网络。我们希望观察网络的运行能力，并找出任何可能的瓶颈。为了实现这一点，我们决定收集以下指标：
- 确认时间中位数
新区块建立前网络达成共识的时间，这个时间是否在荷载作用下随时保持一致。
- 操作数：
在每个分类账中包含的业务量（“交易”）。
- 网络响应：
同时接收处理其他事务时对传入事务的节点响应时间。
术语
上面的一些术语可能看起来很奇怪，你可能不知道操作或分类账真正的意思。在恒星和联邦共识模型中使用的术语和通常在工作量证明项目比如比特币和以太坊中的术语有所不同。下面是对这些术语的简短解释。其中的一些定义直接从恒星官方指南引用。
- 分类账：恒星用给定的时间点的期限分类账来代表网络状态。因此，最后的分类账是当前状态，创世分类账是账本历史第一个状态，关闭分类账意味着将一组事务应用于当前分类帐。因此，分类账账可以被认为是比特币术语中的一个区块，然后更新和关闭作为增加一个区块。
- 操作：一个操作是一个改变分类账的命令。在比特币和以太坊上叫做一笔交易。
- 事务：事务由一组操作组成。这就是你在网络上传输的内容。这实际上意味着您可以在单个请求中向网络提交多个改变分类账的操作。
- Stellar Core：Stellar core负责直接与恒星对等网络进行通信和维护。等同于比特币和以太网络上的节点。
- Horizon：恒星提供了一个Web应用程序，使得更容易与恒星网络进行交互。它提供了一个简单的接口，允许您向网络提交事务、检查帐户状态、订阅事件流等。这对于移动客户端是一个很好的解决方案，移动客户端不需要搭建节点，只需要向远程节点提交HTTP请求。
网络性能方面的考虑
恒星官网介绍，分类账每5秒同步一次。这也可以通过恒星仪表板的实时数据来验证。此外，该协议允许每个分类账包含最多50个事务，每个事务最多可以进行100次操作。这意味着多达5000个操作可以包含在一个分类帐中，这是1000笔操作，每秒平均10个事务。
在Kin系统客户端（如移动和Web应用程序）网络中最常见的用途是传输包含单个操作的事务——最有可能是数字服务的付费操作。这使得聚合操作变得不切实际，限制了我们使用当前协议版本每秒平均执行10次的操作。然而，恒星团队意识到了这一点，并且正在就更新网络限制从基于阈值到基于操作的问题进行持续的讨论。(查阅更多信息stellar-core #1030, stellar-protocol #75.)
以上的结论是，我们需要测试Kin系统的常见情况——主要看恒星能否一贯的处理（每一次操作）一系列10笔每秒的事务。
测试结构和考虑
- 在全球的不同位置设置四个压力测试实例：美国东西海岸、中欧和南太平洋。在提交来自不同地点的事务时，应该平均地显示网络性能的差异
- 每个实例控制120个账户，每个账户有足够的资金在测试过程中生成成千上万笔交易。
- 每个实例在本地运行Stellar core和Horizon。压力测试应用程序通过HTTP请求向本地Horizon提交事务到本地Stellar core。核应用程序工作在“守望者”模式下。只提交事务和从网络接收更新，但不参与协商一致或帮助其他节点赶上分类帐历史。这个决定是为了在不依赖于我们自己的节点进行验证的情况下观察网络中的其他节点如何处理负载。
- 测试开始后，每个实例使用其帐户以每秒2笔事务的速率将事务传输到网络上。将所有实例相加，就是每秒提交8笔事务。
- 这就为恒星网络的其他用户发送另外2个事务（总共10个）留下了足够多的空间。这样做是为了避免在测试期间消耗网络中所有可用的事务空间。
- 每个提交的事务都包含一个单独的支付操作——这像是Kin的预期情况下，就像我们上面提到的。
- 每个测试将运行三个小时，以验证随着时间的推移我们测量的性能是一致的。此外，我们通过每天的不同时间点和两天的时间进行了四次测试。
80笔操作每秒的压力测试
在不同设置情况下，完成了一个额外的压力测试。我们使用每次事务提交10笔付款操作代替1笔操作。就是测试期间平均每秒钟传输80次支付操作。
事务规模
在三小时的过程中，每个测试提交86400笔事务给恒星公共网络。五个测试就提交432000笔事务。
指标
我们测试的指标如下：
- 提交事务并到其记录给分类帐（将其添加到一个块）的时间差：网络上确认交易的速度有多快。
- Horizon和客户端接口之间的响应时间：接口快速响应是否确认了该交易。
- 事务成功率：提交到分类账的事务有多少是成功的。
测定方法
压力测试应用程序在提交事务给Horizon的同时输出时间戳日志。此外，我们扫描所有分类账（区块），包括我们的事务，并测量它们的提交到区块链上的时间。
然后将这些信息解析并处理成电子表格，以生成百分位数和时间图表。这些图表是给出最终测试结果。
由于我们的测试实例与其他参与网络共识的节点之间的实例时钟有差异，我们注意到时间差而不得不改变我们的测量方法，提前约2.5秒测量时间戳，用来“校准”与分类账之间的时间。
开源压力测试应用
压力测试中处理日志代码，用于绘制图表的数据的开源应用是 github.com/kinfoundation/stellar-load-testing。为了社区的利益，我们将发布后续报告，并提供进一步的实施细则。
Results 结果
事务提交VS分类账记录时间差
这张图显示了提交事务并记录到分类账的时间，以毫秒为单位，以百分数的测试运行。结果如下：
- 50%的事物在提交后3-5秒内记录。
- 75%的事物在6-7.5秒之间记录
- 95%的事物在5秒时记录
由于分类账平均关闭时间为5秒，这意味着每笔事物都有95%的机会被添加到下一个分类账或一个之后。真的很快！
注意，每秒80笔的“重量级”操作都有相同的（良好）的性能。
事物提交VSHorizon响应时间差
这张百分位数图显示事物提交到Horizon获得响应的时间。Horizon复制像Stellar core提交事务，等待它达成共识，缓存此信息，并返回响应。可以理解的是，它的运作比Stellar core稍长一些。结果表明：
- 50%的事物提交到获得响应的时间是5-10秒
- 75%的时间是5秒
- 95%的时间是15秒
请注意，即使Horizon还没有回应，上面的提交时间结果表明，交易已经被记录到分类帐上了。
事物成功率（Horizon）
事物成功率
主要四项压力测试的成功率接近100%。令人印象深刻。失败的事务在重新传输后成功
对恒星开发团队说的话
给恒星开发团队一个大大的赞。
在压力测试过程中，我们有大量的技术和设计问题，恒星团队被证明是一个了不起的团队。他们反应迅速，而且非常专业。
值得注意的一件事是在压力测试期间，在Horizon发现的小性能问题导致了比预期高的响应时间。开发团队意识到了这个问题，很快就转身去解决它，在发现问题的几周时间内进行修复，你可以在Github上查看进展——horizon #316。
总结
对整个网络进行压力测试是一项具有挑战性的任务，它涉及到许多长期而彻底的设计、编码、处理和报告任务。
最后，结果表明恒星确实是Kin系统的最佳候选者。它符合我们最重要的要求——即可预测费用、网络稳定性和短确认时间。此外，恒星有一个强大和快速响应的开发团队支持，他们不断改善性能减少错误，处理Bug。
如上面提到的，我们会继续发布帖子，并让您了解我们的恒星集成。
如果你有任问题欢迎提交到我们的Subreddit。
原文：https://medium.com/@oryband/64c4d8676e69