任何推荐的Java分析教程？ [英] Any recommended Java profiling tutorial?

问题描述

是否有任何推荐的Java应用程序分析教程？

Is there any recommended Java application profiling tutorial?

我现在正在使用 JProfiler 和 Eclipse Test&性能工具平台（TPTP）与我的分析。然而，尽管配备了很棒的武器，作为Java新概要的新手，我仍然缺少指出瓶颈的一般理论和技巧。

I am now using JProfiler and Eclipse Test & Performance Tools Platform (TPTP) with my profiling. However, although equipped with wonderful weapons, as someone new to new in Java profiling, I am still missing the general theory and skill in pinpointing the bottleneck.

推荐答案

分析是一个有多个思想流派的学科。

Profiling is a subject having more than one school of thought.

更受欢迎的是你通过测量进行 >。也就是说，您尝试查看每个函数需要多长时间和/或调用它的次数。显然，如果一个函数花费很少的时间，那么加速它将获得很少的收益。但如果需要花费很多时间，那么你必须做一些侦探工作来弄清楚功能的哪个部分对时间负责。不要指望函数时间加起来总时间，因为函数互相调用，而函数A可能需要花费很多时间的原因是它调用函数B也需要花费很多时间。

The more popular one is that you proceed by getting measurements. That is, you try to see how long each function takes and/or how many times it is called. Clearly, if a function takes very little time, then speeding it up will gain you little. But if it takes a lot of time, then you have to do detective work to figure out what part of the function is responsible for the time. Do not expect function times to add up to total time, because functions call each other, and the reason function A may take a lot of time is that it calls function B that also takes a lot of time.

这种方法可以发现很多问题，但这取决于你是一个好侦探，能够清楚地思考不同的时间，如挂钟时间与CPU时间，以及自我时间与包容时间。例如，应用程序可能看起来很慢，但功能时间可能都报告为接近零。这可能是由程序进行I / O绑定引起的。如果I / O是您期望的，那可能没问题，但它可能正在做一些您不知道的I / O，然后您又回到了侦探工作。

This approach can find a lot of problems, but it depends on you being a good detective and being able to think clearly about different kinds of time, like wall-clock time versus CPU time, and self-time versus inclusive time. For example, an application may appear to be slow but the function times may be all reported as near zero. This can be caused by the program being I/O bound. If the I/O is something that you expect, that may be fine, but it may be doing some I/O that you don't know about, and then you are back to detective work.

对于分析器的一般期望是，如果你可以修复足够的东西以获得10％或20％的加速，这是相当不错的，我从来没有听说过重复使用分析器的故事，以获得更多的加速那个。

General expectation with profilers is that if you can fix enough things to get a 10% or 20% speedup, that's pretty good, and I never hear stories of profilers being used repeatedly to get speedups of much more than that.

另一种方法不是测量，而是捕获。它的基础是，在程序花费的时间比你想要的更长时间（在挂钟时间内），你想要知道它在做什么，主要是，并找到一种方法是阻止它并询问，或者对其状态进行快照并对其进行分析，以便完全了解它的作用以及为什么在该特定时间点进行该操作。如果您多次执行此操作并且您看到它多次尝试执行的操作，那么您可以有效地优化该活动。不同之处在于你没有要求多少;你问什么和为什么。 这是另一种解释。（请注意，采取此类措施的速度快照并不重要，因为你不是在问时间，而是在询问程序正在做什么以及为什么。）

Another approach is not to measure, but to capture. It is based on the idea that, during a time when the program is taking longer (in wall-clock time) than you would like, you want to know what it is doing, predominantly, and one way to find out is to stop it and ask, or take a snapshot of its state and analyze it to understand completely what it is doing and why it is doing it at that particular point in time. If you do this multiple times and you see something that it is trying to do at multiple times, then that activity is something that you could fruitfully optimize. The difference is that you are not asking how much; you are asking what and why. Here's another explanation. (Notice that the speed of taking such a snapshot doesn't matter, because you're not asking about time, you're asking what the program is doing and why.)

对于Java， 这里有一个低-tech但非常有效的方法，或者你可以使用Eclipse中的暂停按钮。另一种方法是使用特定类型的分析器，一个对整个调用堆栈进行采样，在壁钟时间（不是CPU，除非你想对I / O无视），当你想要它进行采样时（例如，不是在等待用户输入时），并在代码行级别汇总，而不仅仅是功能级别和时间百分比，而不是绝对时间。为了获得时间的百分比，它应该告诉您，对于任何样本上显示的每行代码，包含该行的样本百分比，因为如果您可以使该行消失，您将保存该百分比。 （你应该忽略它试图告诉你的其他事情，比如调用图，递归和自我时间。）很少有符合这个规范的分析器，但是一个是 RotateRight / Zoom ，但我不确定它是否适用于Java，可能还有其他。

In the case of Java, here is one low-tech but highly effective way to do that, or you can use the "pause" button in Eclipse. Another way is to use a particular type of profiler, one that samples the entire call stack, on wall-clock time (not CPU unless you want to be blind to I/O), when you want it to sample (for example, not when waiting for user input), and summarizes at the level of lines of code, not just at the level of functions, and percent of time, not absolute time. To get percent of time, it should tell you, for each line of code that appears on any sample, the percent of samples containing that line, because if you could make that line go away, you would save that percent. (You should ignore other things it tries to tell you about, like call graphs, recursion, and self-time.) There are very few profilers that meet this specification, but one is RotateRight/Zoom, but I'm not sure if it works with Java, and there may be others.

在某些情况下，在实际缓慢的时候，可能很难在需要时获取堆栈样本。然后，由于您所追求的是百分比，您可以对代码执行任何操作，以便在不改变百分比的情况下更轻松地获取样本。一种方法是通过在100次迭代周围包裹一个临时循环来放大代码。另一种方法是在调试器下设置数据更改断点。这将导致代码被解释为比正常情况慢10-100倍。另一种方法是使用闹钟定时器在慢速期间关闭，并用它来抓取样本。

In some cases it may be difficult to get stack samples when you want them, during the time of actual slowness. Then, since what you are after is percentages, you can do anything to the code that makes it easier to get samples without altering the percentages. One way is to amplify the code by wrapping a temporary loop around it of, say, 100 iterations. Another way is, under a debugger, to set a data-change breakpoint. This will cause the code to be interpreted 10-100 times slower than normal. Another way is to employ an alarm-clock timer to go off during the period of slowness, and use it to grab a sample.

使用捕获技术，如果你使用它反复查找并执行多项优化，您可以期望达到接近最佳的性能。在大型软件的情况下，瓶颈更多，这可能意味着重要因素。 Stack  Overflow上的人报告了7x到60x的因素。 以下是43x的详细示例。

With the capturing technique, if you use it repeatedly to find and perform multiple optimizations, you can expect to reach near-optimal performance. In the case of large software, where bottlenecks are more numerous, this can mean substantial factors. People on Stack Overflow have reported factors from 7x to 60x. Here is a detailed example of 43x.

捕获技术很难解决线程在何时等待的原因，例如等待事务在另一个处理器上完成时。 （测量有同样的问题。）在这些情况下，我使用一种费力的方法来合并带时间戳的日志。

The capturing technique has trouble with cases where it is hard to figure out why the threads are waiting when they are, such as when waiting for a transaction to complete on another processor. (Measuring has the same problem.) In those cases, I use a laborious method of merging time-stamped logs.

这篇关于任何推荐的Java分析教程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！