仅使用单元测试很难找到 Java 应用程序中的所有瓶颈、死锁和内存泄漏。
我想为我的应用程序添加某种程度的压力测试。我想测试应用程序的限制并确定它在高负载下的反应。
我想评估以下内容：
在正常负载下测量和对比这些特性也会很有趣。
是他们众所周知的解决压力测试的标准技术。 我正在寻找建立这样一个环境的帮助/方向。 理想情况下，我希望定期运行这些测试，以便我们确定最近的交付是否会影响性能。
【问题讨论】：
标签： java jakarta-ee testing load-testing performance-testing
我是JMeter 的忠实粉丝。您可以直接针对服务器设置调用，就像用户访问它一样。您可以控制用户（并发线程）和访问的数量。它可以遵循工作流程，逐页抓取相关信息。需要 1 到 2 天的时间来学习它以提高工作效率。 （您可以在下载后一个小时内完成基础操作！）
至于看看这一切如何影响服务器，这是一个更棘手的问题。我使用过 CA 和 IBM 的专业工具。 （我在特定工具名称上画了一个空白 - 可能是由于 PTSD！）我使用了开箱即用的 JVM 分析器。我使用过本机 linux 和 windows 工具。如果您不太关心分析应用程序的哪些部分会导致问题，那么您可以使用操作系统的本机工具来监控 CPU/内存/IO。
【讨论】：
我们的标准技术之一是运行stepped-ramp load tests 来衡量可扩展性。
【讨论】：
应用程序的性能主要有两种方法：
性能测试和系统测试
它们有何不同？这很容易，它基于它们的范围，性能测试的范围是有限的并且非常不切实际。示例：在某个 App X 上测试 IncomingMessage 处理程序，为此您将设置一个测试，以 X、Y、Z 为基础向该处理程序发送消息。这种方法将帮助您确定问题并测量应用程序中单个和有限区域的性能。
所以现在这应该带您回答问题，我是否要单独对我的应用程序中的每个组件进行基准测试和性能测试？是的，如果您认为组件的行为至关重要并且对新版本的更改可能会导致性能下降。但是，如果您想了解整个应用程序、一堆组件之间的交互并了解性能如何，那么您需要进行系统测试。
系统测试将始终尝试尽可能接近地复制任何客户生产环境。在这里，您可以观察应用性能的真实感受，并采取相应措施进行纠正。
因此，作为结论，在您的应用上设置系统测试并测量您所说的想要测量的内容。然后对整个系统施加压力，看看它是如何反应的，你会对结果感到惊讶。
最后，对您已识别或希望在您的应用中跟踪的任何关键组件单独进行性能测试。
作为一般准则，在进行表演时，您应该始终： 1.- 获取系统处于空闲状态的基线。 2.- 在正常预期负载下获取系统的基线。 3.- 获取系统在压力条件下的基线。
请记住，法向负载结果应外推到应力条件，一个好的系统将始终是线性扩展的系统。
希望这会有所帮助。
附：测试、环境设置甚至数据收集都应尽可能完全自动化，这将帮助您在基础上运行它并花时间诊断性能问题而不是设置测试。
【讨论】：
正如其他人所提到的； JMeter 等工具（LoadRunner 等商业工具等）可以帮助您生成并发测试负载。
许多监控工具（一些在 JDK 中提供，如 MissionControl，其他一些开源/免费工具，如 java Melody 和许多商业工具）可以帮助您对各种系统（内存、CPU、网络带宽）和 JVM 资源（堆、CPU）进行通用监控，GC开销等）。
但是要以非常快速和简单的方式真正识别代码中的瓶颈以及应用程序的其他依赖项（如调用的外部服务、数据库查询/更新等）；我建议考虑一个好的 APM，即 AppDynamics/DynaTrace 等应用程序性能监控工具。它们可以帮助您查明特定请求级别的瓶颈，突出显示应用程序的较慢部分，在单个服务端点或组件/方法级别生成百分位指标等。如果处理非常高的并发用户和严格的响应，它们可能非常有用时间 NFR 的。它们有助于发现应用程序各层的许多瓶颈。许多人甚至在生产中配置这些工具（预计会导致 2-3% 的开销；但对我来说它们提供的好处是值得的）——因为默认情况下生产日志不在调试级别；所以一旦观察到一些错误或缓慢;在较低的环境中重现或在没有特定过去持续时间的调试级别日志的情况下进行调试通常非常困难。
【讨论】：
据我所知，没有一种工具可以解决这个问题。所以建立你自己的环境
【讨论】：