12

仅使用单元测试很难找到 Java 应用程序中的所有瓶颈、死锁和内存泄漏。

我想为我的应用程序添加某种程度的压力测试。我想测试应用程序的限制并确定它在高负载下的反应。

我想衡量以下几点：

  • 高负载下的可用性
  • 高负载下的性能
  • 高负载下的内存/CPU/磁盘使用率
  • 它是在高负载下崩溃还是反应优雅

在正常负载下测量和对比这些特性也会很有趣。

是他们众所周知的标准技术来解决压力测试。我正在寻找建立这样一个环境的帮助/方向。理想情况下，我想定期运行这些测试，以便我们确定最近的交付是否会影响性能。

4

5 回答 5

6

I am a big fan of JMeter. You can set up calls directly against the server just as users would access it. You can control the number of user (concurrent threads) and accesses. It can follow a workflow, scraping pertinent information page to page. It takes 1 to 2 days to learn it well enough to be productive. (You can do the basics within an hour of downloading!)

As for seeing how all that affects the server, that is a tougher question. I have used professional tools from CA and IBM. (I am drawing a blank on specific tool names - maybe due to PTSD!) I have used out-of-the-box JVM profilers. I have used native linux and windows tools. If you are not too concerned about profiling what parts of your application causes issues, then you can just use the native tools for your OS to monitor CPU/Memory/IO.

于 2013-10-17T20:26:43.547 回答
1

我们的标准技术之一是运行阶梯式负载测试来测量可扩展性。

于 2013-09-23T12:15:18.570 回答
1

应用程序的性能主要有两种方法：

性能测试和系统测试

它们有何不同？这很容易，它基于它们的范围，性能测试的范围是有限的并且非常不切实际。示例：在某个 App X 上测试 IncomingMessage 处理程序，为此您将设置一个测试，以 X、Y、Z 为基础向该处理程序发送消息。这种方法将帮助您确定问题并测量应用程序中单个和有限区域的性能。

所以现在这应该带您提出问题，那么我是否要单独对我的应用程序中的每个组件进行基准测试和性能测试？是的，如果您认为组件的行为至关重要并且对新版本的更改可能会导致性能下降。但是，如果您想了解整个应用程序，一堆组件之间的交互并查看性能如何，那么您需要进行系统测试。

系统测试将始终尝试尽可能接近地复制任何客户生产环境。在这里，您可以观察应用程序性能的真实感受，并采取相应措施进行纠正。

因此，作为结论，在您的应用程序上设置系统测试并测量您所说的想要测量的内容。然后对整个系统施加压力，看看它是如何反应的，你会对结果感到惊讶。

最后，性能单独测试您已识别或希望在您的应用程序上跟踪的任何关键组件。

作为一般准则，在执行性能时，您应该始终： 1.- 获取处于空闲状态的系统的基线。2.- 在正常预期负载下获取系统的基线。3.- 在压力条件下获取系统的基线。

请记住，法向载荷结果应该外推到应力条件，一个好的系统将始终是线性缩放的系统。

希望这可以帮助。

PS 测试、环境设置甚至数据收集应该尽可能完全自动化，这将帮助您在基础上运行它并花时间诊断性能问题而不是设置测试。

于 2013-10-17T19:31:31.477 回答
0

正如其他人所提到的；JMeter 等工具（LoadRunner 等商业工具等）可以帮助您生成并发测试负载。许多监控工具（一些在 JDK 中提供，如 MissionControl，其他一些开源/免费工具，如 java Melody 和许多商业工具）可以帮助您对各种系统（内存、CPU、网络带宽）和 JVM 资源（堆、CPU）进行通用监控，GC开销等）。
但是要以非常快速和简单的方式真正识别代码中的瓶颈以及应用程序的其他依赖项（如调用的外部服务、数据库查询/更新等）；我建议考虑一个好的 APM，即 AppDynamics/DynaTrace 等应用程序性能监控工具。它们可以帮助您查明特定请求级别的瓶颈，突出显示应用程序的较慢部分，在单个服务端点或组件/方法级别生成百分位指标等。如果处理非常高的并发用户和严格的响应，它们可能非常有用时间 NFR 的。它们有助于发现应用程序各层的许多瓶颈。许多人甚至在生产中配置这些工具（预计会导致 2-3% 的开销；但它们提供的好处对我来说是值得的） - 因为生产日志记录默认不在调试级别；所以一旦观察到一些错误或缓慢; 在较低的环境中重现或在没有特定过去持续时间的调试级别日志的情况下进行调试通常非常困难。

于 2018-04-18T06:56:50.533 回答
0

据我所知，没有一种工具可以解决这个问题。所以建立你自己的环境

  • 负载注入和脚本：JMeter、SOAP UI、LoadUI
  • 调度测试和自动化：Jenkins、Rundeck
  • 事务数据、资源、应用程序性能日志分析：AppDynamics、ElasticSearch、Splunk
  • 分析：AppDynamics、YouKit、Java Mission Control、VisualVm
于 2018-04-18T18:39:18.233 回答