负荷生成的脑投

建筑（30）， 负载测试（1）， Braindump（1）

条纹开始在西雅图建造一个装载一团团队（这是旧金山的帖子，也为西雅图工作），因此我最近一直在考虑加载一代。特别是，我一直在想，我对这个话题不那么了解了比我想的那么多，所以这里是一个集合来源和阅读笔记。

希望，我会很快综合这些可读的东西！

有趣的问题

也许是因为许多公司永远不会为负载生成开发成熟解决方案，因为没有开源解决方案的命令广泛的意识（可能是JMeter之外？），它往往是一个更具意见的地方，而不是平均值，因此有很多几乎没有思考的有趣问题。

让我们开始探索一些人。

  1. 你应该加载测试吗？令人惊讶的是，很少有公司投入负载测试，所以如果你的话永远不会完全清楚应该投资于给定的时间点。My anecdotal impression is that companies which “believe in QA” tend to invest into load testing early, because they have dedicated people who can build the tooling and integration, and that most other companies tend to ignore it until they’re doing a significant amount of unplanned scalability investment. Said differently, for most companies load testing is a mechanism to convert unplanned scalability work into planned scalability work.

  2. 你应该加载测试，redux吗？超出您是否应该投资建设负载测试工具，我的同事博语建议是一个有趣的观点，即通过周到的仪器和对现有流量的分析，也可以获得负载测试产生的大多数度量。

  3. 您应该如何加载测试的基础设施层？Depending on the application you’re running, it may be easy to generate load against your external interfaces (website, API, etc) but as you go deeper into your infrastructure you may want to run load against a specific service or your stateful systems (Kafka, databases, etc).

  4. 您应该在哪些环境下进行测试？也许在滚出负载测试时最常见的参数是您是否应该将其与现有的QA环境进行运行，反对专用的性能环境，或针对您的生产环境来运行。这取决于您正在测试的图层的大量优势，如果您正在进行加载（系统如何对此流量作出反应？）或压力（系统会在哪个负载发生故障？）测试。

  5. 你应该如何建模你的流量？从死人开始围城，有很多不同的方法可以考虑生成负载。您是否应以高并发发出一些请求模式？您是否应使用状态机建模您的流量（在简单脚本中编写编码，或者在DSL中编写），或者您应该只需重播消毒的生产流量？

  6. 是一体化测试和负载测试的区分只是一个规模的问题？在开始考虑它时，集成测试正在运行对服务器的请求，并确保结果是合理的，这与负载测试完全相同。尝试用一个工具解决这两个问题是非常诱人的。

  7. 您应该如何配置加载测试？那个配置在哪里生活？融入整个“是配置代码？”辩论，您的负载测试的配置在哪里？理想情况下，它将在您的服务的存储库中，对吗？或者也许它应该存储在某处的动态配置数据库中，以允许更多有机探索和测试？唔。

好吧，随着这些问题，有时间阅读一些论文。

压力和负载测试研究

作为我的研究的一部分，我跑进了优秀的压力和负载测试论文列表来自德克萨斯州大学的软件工程研究组。许多这些论文都从那里拉了，这也是你阅读的一个伟大的起点！

支持负载测试分析的方法

支持负载测试分析的方法（2010）从一个很好的思考开始，为什么装载测试变得越来越重要和复杂：

对于[超大尺度系统]，分析师不可能通过大量的性能计数器略微浏览所需信息。相反，分析师使用过去的实践，性能大师和域趋势是“拇指规则”的一些​​关键性能计数器。在ULSS中，没有一个人具有完全了解结束以结束地理分布的系统活动。

这对我的经验为真实。

随着系统越来越复杂的，实际上很难找到性能扼流点，并且负载测试是为了提供分布式系统等效的分布式系统。（这也是为什么QA环境充满了失败：由于系统变得越来越复杂，创建有用的完整变得相当困难。）

其他一些有趣的想法：

  1. 相当朴素的软件可以批量高度相关的指标，大大减少人类的搜索空间，了解事物正在降级的地方。
  2. 大多数测试设计意味着它们只能偶尔运行（而不是连续地运行），以及干扰工作负载（例如，在负载测试期间发生的每周批量作业）可以轻松地使那些不经常运行的数据的数据无效。
  3. 许多测试最终会在QA这样的非生产环境中运行时，例如运行QA时，例如运行undowsed或Mix配置的数据库。
  4. 他们使用“主成分分析”来查找最小的主成分不是相互关联，因此您可以探索冗余数据。
  5. 在找到关键主成分之后，他们然后将那些回到底层计数器，以进行进一步分析。
  6. Ideally, you should be able to use historical data to build load signatures, such that you could quickly determine if the system’s fundamental constraint has shifted (e.g. you’ve finally fixed your core bottleneck and got a new one, or something else has degraded such that it is not your core bottleneck).

特别是，我的带走的是，可能是正确的负载生成工具将从手动识别的关键指标开始以相当简单的方法开始，然后越来越多地移动到使用机器学习，以避免我们系统的隐含偏差应该变慢。

在地理位置的统一负载发电机......

用于网络流量的地理分布生成的统一负载发生器（2006年）是硕士学位，恰好是对负荷发电的学术思想和主题的一个非常出色的调查。

这里有趣的想法之一是：

为了设计一个准确的人工负载发生器，该发生器负责在不同的情况下以灵活的方式采用，我们不仅需要一种负载模型，而且需要一种规范现实负载的正式方法。

I’m not sure I entirely agree that we need a formal model to get value from our load testing, we are after all trying to convert unplanned scalability work into planned scalability work, but I have such an industry focus that it’s a fascinating idea to me that you would even try to create a formal model here.

它还引入了更具体的词汇表来讨论负荷生成：

工作负载或负载L = L（e，s，if，t）表示在TimeInterval T期间经由明确定义的接口通过定义的接口提供的环境E对服务系统S提供的总序列。

也许更有趣的是，强调如何服务质量迫使我们重新定义负载测试的目标：

能够提供电信网络的需求，以提供数据，语音和视频，例如向用户提供可接受的QoS级别的传播服务，以及它们的成功取决于有效拥塞控制方案的发展。

我发现这是一个迷人的点。由于您的系统开始包括更系统的负载脱落机制，因此将它们推出均衡而越来越具有挑战性，因为它们（通常）保护通过降解产量收获。因此，它不足以说，您的系统应该或不应该在给定的负载级别失败，如果基于负载级别，您也必须开始测量。

在第3.5节中，它解释（看似众所周知，尽管不给我）Unilog，也称为统一的负载发生器。（也许是基于的这篇报告，悲伤地隐藏在PayWall后面。）Unilog拥有一个有趣的架构，具有令人兴奋的架构，令人兴奋地令人兴奋的令人兴奋的组件名称，如PLM，ELM，GAR，LT，调整和EEM。尽我所能，我可以告诉它是用于运行和评估负载实验的极其通用的架构。从我的第一次阅读中感觉略显过分，但也许随着人们花费更多时间在装载生成的洞穴中，它开始更有意义。

在第4.4节中，它讨论了集中式与分布式负载生成，这感觉像您需要为建立这样的系统所需的核心设计决策之一。我的感觉是你可能想要在某些时候想要分布式方法，如果只是避免通过在每IP Ratelimit上运行的QoS完全节流。

其余文件侧重于某种案例研究。总体而言，这是对相关研究的令人惊讶的彻底介绍。

载荷测试结果自动分析

载荷测试结果自动分析看看使用自动化来了解负载测试结果（使用负载测试期间的负载测试和整体系统度量的执行日志）。

它总结了分析负载测试结果的挑战：过时的文档，过程级分析成本越来越高，负载测试通常发生在开发周期中的短时间内，并且负载测试的输出可能会大大大。

我认为对我来说最有趣的带走是从分析中非常明确地解耦了性能数据的收集的想法。例如，您可以早期开始记录性能数据（并且可能是您的度量工具，例如，石墨，已经捕获该数据），并在稍后投入更复杂的分析。特别侧重于对多重负载测试运行的结果进行比较，这可以在您的度量标准中的性能“生命”的位置最小。

更多论文......

一些摘要的一些额外文件：

将用户转换为测试人员- 本文讨论将用户流量作为负载测试的输入讨论，其目标是减少时间花费加载生成脚本。

自动反馈，基于控制，应力和负载测试- 本文探讨了尝试驱动和维护系统的系统的系统到目标阈值的概念。这是一个有趣的想法，因为这将允许您始终如一地运行对生产环境的负担。唯一的警告是，您必须首先识别要用于影响该负载的输入，因此您仍然需要建模传入流量，以便将其用作输入（或记录和消毒真实流量），但至少once you have modeled it you could be more abstract in how you use that model (if your target is to create load, you don’t necessarily need to simulate realistic traffic, and you could use something like an n-armed bandit approach to “optimize” your load to generate the correct amount of load against the system). (Similarly,本文试图使用遗传算法。）

现有工具

令人惊讶的是，负载测试工具很少，虽然维基百科有一个简短的名单。那个清单，我实际使用了jmeter.几年前，我很享受这对HP的LoadRunner工具短咆哮。

我简要介绍了格子，这是一种在Scala中写的轻量级DSL，可以通过Jenkins轻松运行。这似乎是构建负载生成工具的有趣潜在的起点。特别是将您的负载测试视为您将检查到存储库的概念感觉对，允许您迭代您的负载测试，就像其他任何东西一样。阅读一些其他博客帖子在Gatling上给了我一个更强烈的感觉，这可能是整体负载测试系统的有用组件（允许，例如，许多要针对不同端点或这样的情况）。

还有其他人我错过了吗？

根据...的Web工作量生成

顾名思义，根据Unilog方法的Web工作量生成看着将Unilog方法调整到网络上。它很好地总结了Unilog的方法：

底层的基本原理是unilog的基本原则一直是从抽象负载模型的正式描述开始，此后要使用界面依赖的适配器将抽象请求映射到具体请求，因为它们被服务“被理解”在有问题的真实界面处提供组件。

探索生成请求的方法也是一项很好的工作，尽管再次使用现有流量的日志或生成定义工作负载的模型来返回到任何一种。这里有一个有趣的混合动力车，它将使用实际使用的分布作为所生成的负载的输入（而不是在一对一的基础上使用负载）。

遗憾的是，我并没有真正从中得到太多。