性能/压力测试 Java EE 应用程序

Performance / Stress Testing Java EE applications

提问by cmd

It's difficult to find all bottlenecks, deadlocks, and memory leaks in a Java application using unit tests alone.

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

I'd like to add some level of stress testing for my application. I want to test the limits of the application and determine how it reacts under high load.

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

I'd like to gauge the following:

我想衡量以下几点：

• Availablity under high load
• Performance under high load
• Memory / CPU / Disk Usage under high load
• Does it crash under high load or react gracefully

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

It would also be interesting to measure and contrast such characteristics under normal load.

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

Are their well known, standard techniques to address stress testing. I am looking for help / direction in setting up such an environment. Ideally, I would like to run these tests regularly, so that wecan determine if recent deliveries impact performance.

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

回答by CMerrill

One of our standard techniques is running stepped-ramp load teststo measure scalability.

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

回答by bubooal

There are mainly two approaches for performance on an application:

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

Performance test and System Test

性能测试和系统测试

How do they differ? Well it's easy, it's based on their scope, Performance tests' scope is limited and are highly unrealistic. Example: Test the IncomingMessage handler on some App X, for this you would setup a test which sends meesages to this handler on a X,Y,Z basis. This approach will help you pin down problems and measure performance of individual and limited zones on your application.

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

So this should now take you to the question, so am I to benchmark and performance test each one of the components in my app individually? Yes if you believe the component's behavior is critical and changes on newer versions are likely to induce performance penalties. But, if you want to get a feel on your application as a whole, the bunch of components interacting with each other and see how performance comes out, then you need a system test.

所以现在这应该带您进入一个问题，那么我是否要分别对我的应用程序中的每个组件进行基准测试和性能测试？如果您认为组件的行为很关键并且更新版本的更改可能会导致性能下降，则可以。但是，如果您想从整体上了解您的应用程序、相互交互的一堆组件并了解性能如何，那么您需要进行系统测试。

A system test will always, try to replicate as close as possible any customer production environment. Here you can observe what a real world feel of your app's performance is like and act accordingly to correct it.

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

So as conclusion,setup a system test on your app and measure what you were saying you wanted to measure. Then Stress the system as a whole and see how it reacts, you will be surprised on the outcome.

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

Finally, Performance test individually any critical components you have identified or would like to keep tracked on your app.

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

As a general guideline, when doing performance you should always: 1.- Get a baseline for the system on an idle state. 2.- Get a baseline for the system under normal expected load. 3.- Get a baseline for the system under stress conditions.

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

Keep in mind that Normal load results should be extrapolated to stress conditions, and a nice system will always be that one which scales linearly.

请记住，正常负载结果应该外推到应力条件，一个好的系统将始终是线性扩展的系统。

Hope this helps.

希望这可以帮助。

P.S. Tests, envirnoment setup and even data collection should be as fully automated as possible, this will help you run this on a basis and spend time diagnosing performance problems and not setting up the test.

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

回答by duane musser

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!)

我是JMeter 的忠实粉丝。您可以直接针对服务器设置调用，就像用户访问它一样。您可以控制用户（并发线程）和访问的数量。它可以遵循工作流程，逐页抓取相关信息。需要 1 到 2 天的时间才能充分学习以提高生产力。（您可以在下载后的一个小时内完成基础操作！）

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.

至于查看所有这些如何影响服务器，这是一个更棘手的问题。我使用过来自 CA 和 IBM 的专业工具。（我在特定工具名称上画了一个空白 - 可能是由于 PTSD！）我使用了开箱即用的 JVM 分析器。我使用过原生 linux 和 windows 工具。如果您不太关心分析应用程序的哪些部分会导致问题，那么您可以使用操作系统的本机工具来监控 CPU/内存/IO。

回答by Niranjan Damle

As mentioned by others; tools like JMeter (Commercial tools like LoadRunner and more) can help you generate concurrent test load. Many monitoring tools (some provided within JDK like MissionControl, some other open source/ free tools like java Melody and many commercial one's) can help you do generic monitoring of various system (memory, CPU, network bandwidth) and JVM resources (Heap, CPU, GC overheads etc).
But to really identify bottlenecks within your code as well as other dependencies of your applications (like external services invoked, DB queries/updates etc) in a very quick and easy way; I recommend considering a good APM i.e. Application Performance Monitoring Tools like AppDynamics/ DynaTrace and more. They can help you pinpoint bottlenecks for specific request level, highlight slower parts of apps, generate percentile metrics at individual service end point or component / method level etc. They can be immensely useful , if one is dealing with very high concurrent users and stringent response time NFR's. They help uncover many bottlenecks across the layers of your application. Many even configure these tools in production (expected to cause 2-3% overheads; but worth it per me for the benefits they provide) - as production logging is not at debug level by default; so once some errors or slowness is observed; it's often extremely difficult to reproduce in lower environments or debug in absence of debug level logs from specific past duration.

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

回答by Tharanga Hewavithana

There's no one tool to tackle this as far as I know. So build you own environment

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

• Load Injecting & Scripting: JMeter, SOAP UI, LoadUI
• Scheduling Tests & Automation: Jenkins, Rundeck
• Analytics on transaction data, resources, application performance logs: AppDynamics, ElasticSearch, Splunk
• Profiling: AppDynamics, YouKit, Java Mission Control, VisualVm

• 负载注入和脚本：JMeter、SOAP UI、LoadUI
• 调度测试和自动化：Jenkins、Rundeck
• 对事务数据、资源、应用程序性能日志的分析：AppDynamics、ElasticSearch、Splunk
• 分析：AppDynamics、YouKit、Java Mission Control、VisualVm