软件性能和弹性（恢复能力）是用户体验的关键组成部分，但随着软件行业采用DevOps，它开始在性能和弹性方面出现不足。在软件完全失败之前，性能问题经常被忽略。

但是，我们都知道性能不会突然降低。随着软件通过迭代发布，每次添加更多代码时都会产生性能成本，以及事情可能失败的额外逻辑循环，从而影响整体稳定性。

由于单个代码更改，几乎不会出现致残性能或软件可用性问题。相反，它通常会被一千次削减而死亡。通过严格的实践来增强性能和弹性，并持续测试这些方面，是在问题开始之前解决问题的好方法。与测试的许多方面一样，性能实践的质量远比正在执行的测试数量重要得多。

以下是推动高效性能和恢复能力工程实践的七个简单技巧

1、使用基准测试，一次只更改一个变量
在性能和弹性工程中，基准测试是一种标准化问题或测试，可作为评估或比较的基础。我们定义这样的测试，以便我们可以将它们相互比较。为了进行比较，我们更改了一个元素并测量了该更改对另一个测试的影响。

在我们的持续集成过程中，我们对软件的新版本进行基准测试，以衡量代码更改如何影响我们软件的性能及弹性。在其他一些基准测试中，我们希望衡量我们的软件在不同大小的硬件上的性能表现。由于我们还支持多种体系结构，平台，操作系统，数据库和文件系统，因此我们希望不仅能够定义如何获得最佳性能和可靠性，还能够将它们相互比较。

这些都是有效的基准实践，因为我们改变了一个元素并衡量了这一变化的影响。但是，如果我们要更改测试中的软件版本和我们同时测试的硬件，然后尝试比较结果，我们将无法断定观察到的任何更改是由于一个更改，或者另一个，或两者的结合 - 通常，变化的组合将产生与单独发生时不同的影响。

在性能工程中，尝试进行“苹果对苹果”比较，使用基准测试，并在要比较的多个测试版本中仅更改一个变量。

2、监控内存，CPU，磁盘和网络使用情况
由于性能和弹性工程是一项科学努力，只有通过寻求以可重复的方式客观地解释我们观察到的事件才能实现。这意味着我们需要衡量。

对于性能工程，我们不仅要测量我们正在测试的软件，还要测量我们正在测试它的硬件。监控内存，CPU，磁盘和网络使用情况是我们分析的关键。我们还必须了解这些资源是如何分配的，因为它与我们的处理需求有关。

在信息技术方面，我们总是将数据从一个点传输到另一个点并对其进行转换。在这一过程中, 我们增加了冗余；一些冗余是浪费或开销，其中一些是必要的，因为它使我们能够确保数据完整性和安全性。性能工程就是消除开销和增加数据完整性。

3、每次测试至少运行三次
在我们比较测试结果之前，我们需要确保我们想要比较的数字是值得信赖的。每次我们进行测试时，我们都希望如果我们在不同时间在相同条件下运行相同的测试，我们应该得到相同的结果和指标。

但是当我们第一次进行测试时，我们在新条件下没有测试历史记录来决定我们的结果是否可重复。请记住，以前的一个组件不同的测试不能考虑结果的可重复性；只有多次执行相同的测试才能让我们对结果有信心。

我们可以信任的结果是关键因素，因此我建议你不要考虑性能比较测试的结果，除非您至少执行了三次测试。五次甚至更好的保险测试。对于向客户发布或一般可用性版本，还需要执行更多。

4、实现低于3%的结果差异
仍然在结果的主题上，我们必须证明在不同时间重复的相同测试应该产生相同的结果。一个关键指标是主要指标的方差（也称为可变性）。方差是一个度量，表示同一测试的最佳和更差执行的百分比差异。

让我们考虑一个性能测试，其中主要指标是事务中的吞吐量测量。如果我们的测试具有每秒100个事务的最差执行吞吐量和每秒110个事务的最佳执行吞吐量，那么我们的差异将为10％：

方差 = （较大的值–较低的值）/较低的值
（110 - 100）/ 100 = 0.1

同样，对于弹性测试，其中主要指标是以秒为单位的恢复时间，如果我们的测试具有最差恢复时间为5分钟且最佳时间为4分钟，则我们的方差将为25％。

方差是衡量我们的结果是否可信的关键指标。方差小于3％意味着我们的结果是可靠的。3％到5％之间的方差意味着结果是可接受的和可重复的，但是在测试，环境或测试软件的稳定性方面仍有改进的余地。6％到10％之间的方差意味着我们不能重复我们的结果，应该积极调查我们为什么会有如此高的方差。任何方差大于10％的测试都不能用于性能考虑。

5、运行负载测试至少半小时
负载测试通常旨在测量系统在特定用途下的容量。目标是让该系统在最短的时间内处理最大的工作负载而不会失败。对于这些测试的测量来说，实际上有任何基础，在我看来，性能测试运行必须至少持续30分钟。

当你考虑它时，你用15分钟负载测试证明的唯一一件事就是系统可以处理十五分钟的负载。此外，运行越短，它将受到人为变化的影响越大。

在性能工程中，我们还需要预热期，因为第一次执行时首次运行总是较慢。即使在预热系统上，测试的前几个交易可能会更慢，并且在多次运行之间不一定相同 - 因此会出现人为的差异。在30分钟或更长时间的测试中, 这些测试不会显示出来, 诱发差异的可能性也要低得多。

如果负载测试持续时间低于30分钟，从性能工程的角度来看，其结果将没有多大意义。测试至少半小时不包括任何预热期。

6、证明您的负载结果可以持续至少两个小时
我再次建议至少半小时。正如前面所述，只有30分钟的负载测试证明，系统可以承受30分钟的负载。虽然30分钟将足以检测到大多数新的性能变化，但为了使这些测试合法，还必须能够证明它们可以在相同的负载下运行至少两个小时。

如果没有空间耗尽, 高峰负荷应该是无限期可持续的。证明负载可以运行两个小时是很好的开始。我建议将目标目标为6、12和24小时作为里程碑，并在可能的情况下证明在这些负载下可以连续运行5天。

请注意，这些负载耐久性测试旨在证明负载结果的可持续性。它们不需要针对每一个代码更改运行，而只是为了证明负载数量的可持续性。

从证明两个小时是可持续的开始。任何较少的内容和性能数字都不应该用于性能发布, 也绝对不是出于容量考虑。

7、确保良好的自动化程度
没有良好的自动化，你就无法获得成功的性能工程。你是否花费更多时间分析测试结果（良好的自动化），或执行测试并对现有自动化进行改进（自动化程度较低）？

如果您认为可以改进自动化实践，请从以下七个原则开始：