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