跳到主要内容

负载测试

这是一个相当开放的命题。首先要问一些问题，另外还需要一些资源。你将需要一些硬件来运行基准测试/负载测试。许多工具将被证明是有用的。有许多产品需要考虑。最后，为什么 Java 是实现负载测试/基准测试产品的好选择。

17.1 要问的问题 ​

我们预期的平均用户数是多少（正常负载）？

我们预期的用户峰值数量是多少？

什么时候是对我们的应用程序进行负载测试的好时机（即下班时间或周末），记住这很可能会导致我们的一个或多个服务器崩溃？

我们的应用程序有状态吗？如果是这样，我们的应用程序如何管理它（cookie、会话重写或其他方法）？

测试的目的是什么？

17.2 资源 ​

以下资源将证明非常有用。请记住，如果你找不到这些资源，你将成为这些资源。由于你已经为你完成了工作，因此值得知道以下人员是谁，以便你可以在需要时向他们寻求帮助。

17.2.1 网络 ​

谁知道我们的网络拓扑？如果你遇到任何防火墙或代理问题，这将变得非常重要。同样，私有测试网络（因此将具有非常低的网络延迟）将是一件非常好的事情。知道谁可以为你设置（如果你认为有必要）将非常有用。如果应用程序没有按预期扩展，谁可以添加额外的硬件？

17.2.2 应用 ​

谁知道我们的应用程序是如何运作的？正常顺序是

  • 测试（小批量——我们可以对我们的应用程序进行基准测试吗？）
  • 基准（平均用户数）
  • load-test（最大用户数）
  • 破坏性测试（我们的硬性限制是什么？）

测试过程可能会从黑盒测试进展到白盒测试（区别在于第一个不需要应用程序知识[它被视为黑盒]，而第二个需要一些应用程序知识）。在此过程中发现应用程序问题并不少见，因此请准备好捍卫你的工作。

17.3 我应该使用什么平台来运行基准测试/负载测试？ ​

这应该是一个广泛使用的硬件，具有标准（即 vanilla）软件安装。请记住，如果你发布结果，你的客户要做的第一件事就是聘请研究生来验证它们。你不妨尽可能让这个人轻松一点。

对于 Windows，Windows XP Professional 应该是最低要求（其他的不会多线程超过 50-60 个连接，并且你可能预计会有更多的用户）。

好的免费平台包括 linux、BSD 和 Solaris Intel。如果你有更多的钱，还有商业 Linux。如果你需要支持，这可能是值得的。

对于非 Windows 平台，请调查ulimit -n unlimited以将其包含在你的用户帐户启动脚本（用于测试帐户的 .bashrc 或 .cshrc 脚本）中。

另请注意，某些 Linux/Unix 版本旨在供服务器使用。这些通常很少或没有 GUI 支持。这样的操作系统应该可以在 CLI 模式下运行 JMeter，但除非你安装最小的 GUI 环境，否则 JMeter GUI 模式可能无法工作。

随着你进行更大规模的基准测试/负载测试，该平台将成为限制因素。因此，值得使用你可用的最好的硬件和软件。请记住在你发布的基准测试中包含硬件/软件配置。

当你需要大量机器或想要测试网络延迟时，Cloud 可以为你提供帮助。 JMeter 可以轻松安装在云实例上，因为它几乎可以在云中可用的任何架构上运行。如果你不想自己管理 JMeter，Commercial Cloud PAAS 也支持它。

不要忘记 JMeter 批处理 (CLI) 模式。在负载测试期间应使用此模式，原因有很多：

  • 如果你有一个支持 Java 的强大服务器，但可能没有快速的图形实现，或者你需要远程登录。
  • 与使用远程显示或客户端-服务器模式相比，批处理 (CLI) 模式可以减少网络流量。
  • 用于 GUI 模式的 Java AWT 线程有时会通过阻塞来改变注入行为

然后可以将批处理日志文件加载到工作站上的 JMeter 中进行分析，或者你可以使用 CSV 输出并将数据导入电子表格。

记住 GUI 模式是用于脚本创建和调试，而不是用于负载测试

以下工具都将证明是有用的。熟悉它们绝对是值得的。这应该包括试用它们，并阅读适当的文档（手册页、信息文件、应用程序 --help 消息和任何提供的文档）。

17.4.1 ping ​

这可用于确定你是否可以到达目标站点。可以指定选项，以便ping提供与traceroute相同类型的路由报告。

17.4.2 nslookup/挖掘 ​

虽然用户通常会使用人类可读的互联网地址，但你可能希望在执行基准测试/负载测试时避免 DNS 查找的开销。这些可用于确定目标站点的唯一地址（虚线四边形）。

17.4.3 跟踪路由 ​

如果你不能ping你的目标站点，这可能被用来确定问题（可能是防火墙或代理）。它还可以用于估计整体网络延迟（在本地运行应该提供尽可能低的网络延迟 - 请记住，你的用户将在可能繁忙的互联网上运行）。一般来说，跳数越少越好。

17.5 如何增强 JMeter？ ​

有许多开源和商业供应商提供 JMeter 插件或其他资源以供 JMeter 使用。其中一些列在 JMeter Wiki 上。它们分为以下几类：

  • JMeterPlugins - 用于扩展 JMeter 的插件
  • JMeterAddons - 与 JMeter 一起使用的插件，例如浏览器插件、Maven 和 Jenkins。
  • JMeterServices - 3 rd方服务，例如基于云的 JMeter

请注意，这些在 Wiki 上的出现并不意味着 Apache JMeter 项目的任何认可。任何支持请求都应直接发送给相关供应商。

17.6 为什么选择 Java？ ​

为什么不是 Perl 或 C？

嗯，Perl 可能是一个非常好的选择，除了 Benchmark 包似乎给出了相当模糊的结果。此外，使用 Perl 模拟多个用户是一个棘手的命题（可以通过从 shell 脚本派生多个进程来模拟多个连接，但这些不会是线程，它们将是进程）。然而，Perl 社区非常庞大。如果你发现有人已经写了一些看起来很有用的东西，这可能是一个很好的解决方案。

当然，C 是一个非常好的选择（查看 Apache ab 工具）。但要准备好编写所有自定义网络、线程和状态管理代码，这些代码是你对应用程序进行基准测试所需的。

Java 为你（免费）提供了对应用程序进行基准测试所需的自定义网络、线程和状态管理代码。Java 知道 HTTP、FTP 和 HTTPS——以及 RMI、IIOP 和 JDBC（更不用说 cookie、URL 编码和 URL 重写）。此外，Java 还为你提供自动垃圾收集和字节码级别的安全性。